RE: [Simple] Review of draft-garcia-simple-presence-dictionary-04.txt

<krisztian.kiss@nokia.com> Sat, 28 April 2007 17:37 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 1Hhqr2-00032a-NA; Sat, 28 Apr 2007 13:37:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhqr0-00032Q-Ur for simple@ietf.org; Sat, 28 Apr 2007 13:37:02 -0400
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhqr0-0005FT-3V for simple@ietf.org; Sat, 28 Apr 2007 13:37:02 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3SHaolb024752; Sat, 28 Apr 2007 20:36:59 +0300
Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Apr 2007 20:36:46 +0300
Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Apr 2007 12:36:44 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Simple] Review of draft-garcia-simple-presence-dictionary-04.txt
Date: Sat, 28 Apr 2007 12:36:44 -0500
Message-ID: <6231925C3635AF47B2B149033DD9186502F64125@daebe103.NOE.Nokia.com>
In-Reply-To: <OF93F5537D.01B03379-ONC22572C9.002B8BEF-C22572C9.002D78E4@il.ibm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Simple] Review of draft-garcia-simple-presence-dictionary-04.txt
Thread-Index: AceH21Bxk5yEy2aWTlWvMPXecF27UABBEX9w
References: <OF93F5537D.01B03379-ONC22572C9.002B8BEF-C22572C9.002D78E4@il.ibm.com>
From: krisztian.kiss@nokia.com
To: AVSHALOM@il.ibm.com, simple@ietf.org, miguel.garcia@nsn.com
X-OriginalArrivalTime: 28 Apr 2007 17:36:44.0335 (UTC) FILETIME=[C9F27BF0:01C789BB]
X-Nokia-AV: Clean
X-Spam-Score: 0.3 (/)
X-Scan-Signature: fe105289edd72640d9f392da880eefa2
Cc:
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>
Content-Type: multipart/mixed; boundary="===============0493300213=="
Errors-To: simple-bounces@ietf.org

Hi Miguel,
 
I have also reviewed the document. Regarding Avshalom's comment, I think
the draft in its current form provides a good catch of nowadays PIDF and
its extensions. Future extensions may be minor or proprietary, so I
personally don't see a need to introduce versioning and its
client-server negotiation. Certainly this document has to wait until all
dependencies reach stability.
 
Some further minor comments as follow:
 
Section 1: change:
 "The Session Initiation Protocol (SIP) [4] is extended by the
SIP-events framework [5] to provide, e.g., subscriptions and
notifications to presence information.  The presence information is
typically carried in Extensible Markup Language (XML) [22] documents
that are compliant with a given XML schema [23]. For example, the
Presence Information Data Format (PIDF) [8] defines the format for the
basic document that supplies presence information. "
 
with:
 "The Session Initiation Protocol (SIP) [4] is extended by the
SIP-events framework [5] to provide subscriptions and notifications of
events. One example of such event notification mechanism is presence.
The  presence information is typically carried in Extensible Markup
Language (XML) [22] documents that are compliant with a given XML schema
[23]. The Presence Information Data Format (PIDF) [8] defines the format
for the basic document that supplies presence information."
 
Section 1:
"Typically, PIDF is used in combination with other extensions to provide
a richer user experience, among others: the Presence Data Model [10],
Rich Presence Extensions to PIDF (RPID) [11], Contact Information in
PIDF (CIPID) [12], or Timed Presence Extensions to PIDF [13]."
I would remove reference [13] from here and add at least [19] and [20]
(considering what the "typical" extensions are enhancing user
experience...)

 
Section 1:
"Sigcomp endpoints will initially announce the availability of one or
both dictionaries until the other end acknowledges that it has received
the announcement."
Do sigcomp endpoints really announce the availability of RFC3485
dictionary? According to RFC 3485: "The static dictionary is unique and
MUST be available in all SigComp implementations for SIP/SDP"
 
Appendix A (and Section 4 accordingly):
- timestamp could be upgraded to priority 1,
- "close" should be "closed"
- "deviceId"should be "deviceID"
- "country" seems to be missing from PIDF-LO [16]
- "version=" is also included in winfo [17] (reference is missing)

Cheers,
Krisztian



________________________________

	From: ext Avshalom Houri [mailto:AVSHALOM@il.ibm.com] 
	Sent: Thursday, April 26, 2007 1:17 AM
	To: simple@ietf.org; Garcia Miguel (NSN - FI/Helsinki)
	Subject: [Simple] Review of
draft-garcia-simple-presence-dictionary-04.txt
	
	
	
	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