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