Document:  draft-ietf-simple-presence-data-model-06 
Reviewer: Elwyn Davies [elwynd@dial.pipex.com]
Review Date:  Tuesday 12/13/2005 4:22 PM CST
Telechat Date:  Thursday 12/15/2005

Summary: Ready with nits.

Review:
-------

This is an update of my last call review detailing the editorial nits 
which I found during the review plus a discussion of the intended status 
of this document and the documents which it updates as identified by 
Brian Carpenter.

Summary:
Internally the document is ready to progress give or take a few 
editorial nits.   However  it needs to be clarified how it relates to 
the two documents which it asserts that it updates given that the 
intended status of this document is PS and one of the two updated 
documents is an Informational.

The introduction implies that this document updates RFC2778 and RFC3863; 
this needs to be stated both in the abstract and the document header.  
This gives rise to some concerns over the status of the document and the 
references to the two documents which it updates.   There is no problem 
with RFC3863 which is a  PS but RFC2778 is Informational and is 
currently classified as an Informative reference.  So two questions:
- Is this a legitimate way to update RFC2778, and
- If so, should RFC2778 be a 'downref' Normative reference?

Editorial:
s2, para 1:  s/new terms/ additional terms over and above those defined 
in [RFC2778]/

s2, definition of Occurrence: s/document/Presence Information Format 
(PIDF) document/

s2, definition of Status: On first reading I found the original 
definition confusingly vague and apparently meaningless. After reading 
the rest of the document it became clearer what was intended.  Maybe my 
alternative would be clearer on first reading but it is now difficult to 
tell.  s/Generally dynamic information about a service, person or
      device./Information about the disposition of a service, person or 
device which is generally expected to change with time (contrast with 
Characteristic)./

s2, definition of Characteristic: s/Generally static information about a 
service, person
      or device./Information about the disposition of a service, person 
or device which is generally static over time (contrast with Status)./

s3: 'They are the presentity URI...'  The labelling of the diagram seems 
to better convey that the URI is (as I understand) it a label or 
identifier for the presentity rather than the presentity URI itself 
being a componen t of the model.  Maybe this should be 'They are the 
presentity, identified by a URI,....'

s3: s/description about the service/description of some aspect of the 
service/
s3: s/affilitated/affiliated/

s3.1, para 1: 'pres URI' looks like a mistake: s/pres URI/URI from the 
Presence (pres) scheme/

s3.1, para 3: s/Independent of its scheme/Irrespective of the scheme 
feom which the URI is taken/

s3.3, para4: s/There is no central registry by which one goes finds the
   identifiers for each service.  Consequently, each service does not
   have a single "service" attribute that with values of "ptt" or
   "telephony".  That does not mean that these consolidated monikers
   are n't useful;/There is no central registry to which one goes finds the
   identifiers for every service.  Consequently, each service does not
   have a single "service" attribute with values such as "ptt" or
   "telephony".  That does not mean that these consolidated monikers
   are not useful;/

s3.3, para 4: s/is less meaningful to create a summarization/is less 
meaningful as a way of creating a summarization/

s3.3.1, para 1: s/auomata/automaton/

s3.3.1, para 1: s/RFC2533, for example[11]/RFC2533[11], for example,/
s3.3.1, para 1: s/(this service only does voice)/(e,g., this service 
only does voice)/

s3.3.2, para 1: s/are the instructions/provides the instructions/

s3.3.2, para 6: s/Because the reach information serves as an idenfifier 
for a service, it also serves as a way to figure out whether something 
is one service or two./Because the reach information serves as an 
identifier for a service, it also serves as a way to figure out whether 
a communications capability should be represented as one service or more./

s3.3.2, para 6: s/can do audio/is capable of audio/

s3.3.2, para 8: s/are most ideally/is most ideally/
s3.3.2, para 8: s/amount of presence/number of presence/
s3.3.2, para 8: s/bceome incresingly smal/decrease correspondingly/

s3.3.2, para 9: 3 instances of enum s/b ENUM maybe?

s3.3.2, para 9: I think some explanation of the dip indicator might 
help.  This is very obscure to the casual reader.
s3.3.2, para 9: s/it means/it generally means/ perhaps?

s3.3.2, para 10: s/reachable by potentially/reachable through, potentially,/
s3.3.2, para 10: s/infomation/information sets/

s3.3.2, para 11: s/service URI/service URIs/

s3.3.4, para 1: s/either closed or open/either "closed" or "open"/
s3.3.4, para 1, last sentence: s/the communications/that communications/

s3.3.4, para 2: s/eventually get/eventually gets/

s3.3.4., para 4: s/s roaming/is roaming/

s3.4, para 3: s/compostitor/compositor/

s3.4, para 5: s/RECOMMEND/RECOMMENDED/

s3.4, para 12 (I think): s/apriori/a priori/

s3.5, para 2 and para 5: s/automata/automaton/

s7: The introduction claims 'examples' but there is only one.

s7, next to last para: s/voip/VoIP/