draft-ietf-impp-pres-01 (was: WG Last Call on multiple documents (deadline Jan 12))

Detailed comments below.

With respect to matters of scope, function and definition precision, this
spec must, of course, show detail that is comparable to the changes suggested
for CPIM. For example, terms need to be defined explicitly and completely.


For brevity, I have tried not to repeat suggestions here that were already
offered in CPIM but apply equally here.


<<
                        Common Profile: Presence
                        ->
                        Common Profile: Presence  (CPP)
<<



3.1 Overview of the Presence Service

...
   The duration specifies the
   maximum number of seconds that the SUBSCRIPTION should be active
   (which may be zero, in which case this is a one-time request for
   presence information).
<<
   [[ As I recall, there was extensive discussion about the way to specify
   time.  However I do not recall any of the comments about it.

   Perhaps it makes sense to have the request contain a time
   specification in terms of duration.  However it does not seem to make any
   sense to use duration anywhere else in the service.

   How can "duration" have any useful meaning when there is no baseline
   reference for the starting point or ending point of the duration and when
   exchange latencies are completely unpredictable? That is, when a
   participant receives a duration value from another participant, what does
   it mean? Duration relative to what point of time? We do not know how many
   seconds it took for the service data to reach the receiving participant.

   The simplest, global reference for duration is to specify the ending time
   in a global time format.  /d]]
>>


   Note that a notify operation will be invoke when a subscription is
<<
   invoke -> invoked
>>


   prematurely canceled in this fashion; this notification may be
   discarded by the watcher.


3.2 Identification of PRESENTITIES and WATCHERS
<<
  [[ There is no discussion of Watchers in this section.  /d]]
>>

   A PRESENTITY is specified using the PRES URI scheme, which is further
   described in Appendix A.  An example would be:
   "pres:[email protected]"

   To resolve presence URIs, a client determines the address of an
   appropriate system running a server by resolving the destination
   domain name that is part of the identifier to either an intermediate
   relay system or a final target system.
<<
   To resolve presence URIs, a client determines the address of an
   appropriate system running a server by resolving the destination
   domain name that is part of the identifier to either an intermediate
   relay system or a final target system.
   ->
   A Presence URI is resolved incrementally.  The global portion of the
   resolution process finds the server associated with the URI, by resolving
   the domain name portion of that URI.  The semantics of the Pres URI domain
   name are defined in [2].  It will reference either the target server or
   an intermediate server.
>>



3.4.2 The Notify Operation

   The service invokes the notify operation whenever the presence
   information associated with a PRESENTITY changes and there are
   subscribers to that information.
<<
   [[ This might be taken to mean that different subscribers are notified
   differentially, depending upon which bits of information for that
   Presentity have changed.  However, subscribers have no way to specify
   that they want to know about one change for a Presentity, but not
   another.

   So, the above language needs to be something like "...changes and there
   are subscribers requested notification about that Presentity."  /d ]]
>>


   There is no application response to the notify operation.


d/
--
 Dave <mailto:[email protected]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850




  [reminder: [email protected] for non-technical discussions, please]