Re: [Simple] Review of draft-garcia-simple-presence-dictionary-04.txt
Miguel Garcia <Miguel.Garcia@nsn.com> Fri, 27 April 2007 10:23 UTC
Return-path: <simple-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhNbf-0006ge-Li; Fri, 27 Apr 2007 06:23:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhNbe-0006gU-4Z for simple@ietf.org; Fri, 27 Apr 2007 06:23:14 -0400
Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhNbd-00030Q-IR for simple@ietf.org; Fri, 27 Apr 2007 06:23:14 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3RAN3Wg004611; Fri, 27 Apr 2007 13:23:11 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 13:23:04 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 13:23:04 +0300
Received: from [172.21.59.57] ([172.21.59.57]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 13:23:04 +0300
Message-ID: <4631CF08.2010104@nsn.com>
Date: Fri, 27 Apr 2007 13:23:04 +0300
From: Miguel Garcia <Miguel.Garcia@nsn.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Avshalom Houri <AVSHALOM@il.ibm.com>
Subject: Re: [Simple] Review of draft-garcia-simple-presence-dictionary-04.txt
References: <OF93F5537D.01B03379-ONC22572C9.002B8BEF-C22572C9.002D78E4@il.ibm.com>
In-Reply-To: <OF93F5537D.01B03379-ONC22572C9.002B8BEF-C22572C9.002D78E4@il.ibm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Apr 2007 10:23:04.0905 (UTC) FILETIME=[0ABECB90:01C788B6]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org
Hi Avshalom: Thanks for the review. With respect the question on versioning, I would like to point out that the fundamental assumption behind SigComp is that, if there is a dictionary, it is unique, stable, and will not be updated in the future. At least, this was the idea behind the SIP dictionary, and here, the text in RFC 3485: The dictionary is not intended to evolve as SIP or SDP evolve. It is defined once, and stays as is forever. This solves the problems of updating, upgrading and finding out the dictionary that is supported at the remote end when several versions of the same dictionary coexist. The bigger problem with versions of the dictionary is that they constitute separate state. So, version 1 of the dictionary is a standalone dictionary. If you create version 2, then it is a separate dictionary, and the endpoint would have to implement both to have maximum interoperability. Since each dictionary requires storage and RAM memory, you may end up exhausting the resources in the endpoint. It would be possible, though, to create addenda to the existing dictionary, if the need arises. So each addendum would be a separate state that is advertise separately. I think this is the way to go forward (again, if the need arises). As you may have noticed, each dictionary is associated with a state identifier. This is as much as is needed to refer or find out the dictionary, so in my opinion, this is as much as it is needed between the two points to find out that the dictionary is available at the remote endpoint and start using it. I think the state identifier is a hash of the contents of the state (dictionary). /Miguel Avshalom Houri wrote: > > I have reviewed the document and I think that it is a good suggestion > and will > help in reducing the amount of traffic for presence document. > > We may need to have a mechanism for enabling versioning or more flexible > way > to decide on dictionaries. > Unlike SIP and SDP headers which are more or less stable, in presence > things > change all the time and there will be new schemas that will require new > and/or updated dictionaries. > > There should be a way to associate a dictionary with a schema and/or > a way that a client and a server will agree on a version of the > dictionary. > > One typo in section 1. > resources are scare (e.g., such as low bandwidth links with high > >> scare -> scarce > > --Avshalom > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple
- [Simple] Review of draft-garcia-simple-presence-d… Avshalom Houri
- Re: [Simple] Review of draft-garcia-simple-presen… Miguel Garcia
- RE: [Simple] Review of draft-garcia-simple-presen… krisztian.kiss
- Re: [Simple] Review of draft-garcia-simple-presen… Miguel Garcia