Re: draft-ietf-impp-pres-01

Let me make several unrelated and uncontroversial comments on
draft-ietf-impp-pres-01.txt.

***

The use of durations instead of absolute times in subscription
requests makes the most sense to me.

***

In Section 3.4, as Dave pointed out for IM, the paragraph 

   Note that the transaction-identifier parameter used by the service
   is potentially long-lived.  Accordingly, the values generated for
   this parameter should be unique across a significant duration of
   time.

is wrong because a transaction-identifier for a subscription request can be
reused as soon as its matching response is received.

***

The text does not say in what sense a SubscriptID is unique.  Must it
be globally unique?  Must the pair (watcher, SubscriptID) be unique?
Must the triple (watcher, presentity, SubscriptID) be unique?  If the
answer to the third question is yes, than a given watcher need only
generate one SubscriptID, but if the answer to the first question is
yes, it must generate a globally unique identifier for each requested
subscription.

***

"Peterson, Jon" <[email protected]> writes:
....

> We discussed, for example, whether or not we could assume underlying
> reliability of message delivery hop-by-hop, and decided that we
> could and should assume it to be in place. The purpose of the
> response operation is to indicate, from an authoritative source (the
> endpoint or the endpoint's service provider, if the endpoint is
> unavailable) whether or not the message has been delivered. Gateways
> should only generate response operations themselves in error cases,
> when for whatever reason the message is undeliverable.

One must be careful when discussing the purpose of the response
operation to a message request.  There is no common format for
response operations, so they cannot be signed.  Thus, there is no way
to have the same assurance in the authenticity of a response that one
has with a signed message.  Of course, secure IM clients could
acknowledge messages by generating their own signed message to be used
as a secure response.

John



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