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

[Miguel Garcia <[e-mail]>]

Hi Krisztian:

Thanks for your review. I have implemented most of your suggestions in 
my working draft. As for your question:

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

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.

Now, with respect your proposed changes:

 > - 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:
> 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:[e-mail]]
>     *Sent:* Thursday, April 26, 2007 1:17 AM
>     *To:* [e-mail]; 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
> 
> 

-- 
Please note my new e-mail address: miguel.garcia at nsn.com
Miguel A. Garcia           tel:[phone]
Nokia Siemens Networks     Helsinki, Finland


_______________________________________________
Simple mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple