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

More notes inline - again, most of this is fine and will be incorporated.

Does anybody out there have any strong inclination that we should use
absolute time (like DateTime format) for the attribute of the subscription
operation that specifies when subscriptions should begin and end, instead of
(as the text now says) an integer duration? Some notes about that below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dave Crocker [mailto:[email protected]]
> Sent: Monday, January 06, 2003 4:55 PM
> To: [email protected]
> Subject: draft-ietf-impp-pres-01 (was: WG Last Call on multiple
> documents (deadline Jan 12))
> 
[snip]
> 
> <<
>                         Common Profile: Presence
>                         ->
>                         Common Profile: Presence  (CPP)
> <<
> 

Done.

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

I agree that we do not know how many seconds it takes for a message to be
delivered, but we know that it is a matter of seconds and not hours. Using
absolute time of course gives rise to some time synchronization concerns - a
similar trade-off. In either case, there is a certain margin of uncertainty.

One important fact about subscriptions is that they are probably more
long-lived than, say, five or ten seconds. I would anticipate that
subscription refreshes would have a minimal duration of some number of
minutes. An hour seems like a good default for refreshing subscriptions.
When we think in terms of an hour, a difference of a few seconds either way
(for propagation) doesn't seem terribly significant. Time synchronization,
especially for conventional IM&P endpoints like PCs, could result in greater
disparities.

Personally, I think using an integer duration in seconds is quite reasonable
- the duration signifies "expire this subscription [duration] seconds after
you receive this operation". Basically, to use absolute time you'd need to
send your local time, and the time you want the duration to expire either as
another absolute time (fetch and unsubscribe, presumably, would use the same
time for both to effectively express a duration of 0) or as an integer
duration. But since the propagation delay of the message is unknown, even
when the recipient looks at the local time of the sender to calculate when
the subscription expires, they'd have a hard time knowing whether any
disparity between their time and the sender's was the result of propagation
delay or if the clocks merely aren't synchronized.

Gateways could of course convert between systems that used different
notations for duration (provided the gateway has its own reckoning of the
time and can do some simple arithmetic, both of which seem plausible).
Specifying that the abstract attribute of the subscribe operation has an
integer duration shouldn't preclude gateways performing this transformation.

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

Done.

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

Good point... we'll do something about that. The assumption is that the
watcher uses the pres URI one would use to subscribe to their presence. Or
should we allow other URIs? A way of contacting the watcher, maybe?

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

Yes, your text is better.

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

Okay, that sounds good to me.

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



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