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

From: Avshalom Houri <[email-masked]>
Date: Thu, 26 Apr 2007 11:16:42 +0300

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 27 Apr 2007 13:23:04 +0300

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
> ------------------------------------------------------------------------
> 

-- 
Please note my new e-mail address: miguel.garcia at nsn.com
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Helsinki, Finland

---

From: <[email-masked]>
Date: Sat, 28 Apr 2007 12:36:44 -0500

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:[email-masked]] 
	Sent: Thursday, April 26, 2007 1:17 AM
	To: [email-masked]; 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. 

	--Avshalom

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 30 Apr 2007 13:34:42 +0300

Hi Krisztian:

Thanks for your review. I have implemented most of your suggestions in 

 > MUST be available in all SigComp implementations for SIP/SDP"

I believe the text is correct, because I got it from the ROCH mailing 
list. Some ROHC people reviewed the draft and wanted to clarify the 
fuzzy wording we previously had inthere. So, according to the Sigcomp 
experts the endpoint initially needs to announce the presence dictionary
but it can stop when the other endpoint acknowledges that is has
received the announcement. The SigComp END-MESSAGE "returned
parameters" are used to announce the availability of the presence
dictionary and "requested feedback item" is used to ask for
acknowledgement from remote endpoint. So, after the requested
feedback item has been returned to the endpoint there is no need
to continue to announce the presence dictionary or other SigComp
parameters using the returned parameters as "the endpoint is
already satisfied all necessary information has reached the
endpoint receiving the message" (quote from 3320).

With respect the text that you quote from RFC 3485, I don't think it is 
related to the issue you mentioned. Basically, the text was trying to 
say that if you implement SigComp for SIP, you have to implement the 
SIP/SDP dictionary as well. It says nothing about the initialization phase.

 > - timestamp could be upgraded to priority 1,

We used the rule that any string that gets priority 1 means that you 
will always find that string in any presence document, or the likelyhood 
to find the string is very high. That's the reason why there is only a 
few strings with priority 1.  I thought that "timestamp" is an optional 
element in PIDF and the data model, so there will be implementations 
that will not use it at all. I believe this is enough to write any other 
priority than 1. So, priority 2 (the current one) seems to be 
appropriate: it is very likely to find this string in a presence document.

 > - "close" should be "closed"

Oops, yes, it should be closed. Fixed.

 > - "deviceId"should be "deviceID"

Yes. Fixed.

 > - "country" seems to be missing from PIDF-LO [16]

Yes. Added to the strings

 > - "version=" is also included in winfo [17] (reference is missing)

As you can see, there are two similar entries for version. One is 
"version" and the other is "version=" (notice the '='). The former, 
which is listed at the end of the string collection, is used by 
reference [21] as an element. The latter, listed at the beginning of the 
string collection, is used by many documents (including winfo) as an 
attribute. So I should add reference [17] to this last one, but as I 
indicated, there are so many documents that use "version=" that I just 
don't list any document. Therefore, I see no action with this respect.

BR,

         Miguel

Kiss Krisztian (Nokia-SIR/PaloAlto) wrote:
> (considering what the "typical" extensions are enhancing user experience...)
>  
> Section 1:
>     *From:* ext Avshalom Houri [mailto:[email-masked]]
>     *Sent:* Thursday, April 26, 2007 1:17 AM
>     *To:* [email-masked]; Garcia Miguel (NSN - FI/Helsinki)
>     *Subject:* [Simple] Review of