RE: draft-ietf-impp-pres-01

Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, January 08, 2003 8:46 AM
> To: [email protected]
> Cc: [email protected]
> Subject: 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.
> 

Agreed. Now that SubscriptID has been split off from TransID, it is
SubscriptIDs that needs to be long-lived.

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

I assumed it would be intrinsically globally unique. Each time a watcher
issues a new subscription operation, it must use a new SubscriptID. I don't
think this is particularly burdensome.

Incidentally, I think we do want to allow a given watcher to have multiple
subscriptions to the same presentity - that has been accepted as a
requirement. Even if we were not to allow them to exist concurrently, it
would still be useful to differentiate subscriptions over time.

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

We have argued that transitive security is adequate for authenticating
operations that have no e2e content to which gateways should not be privy.
MSGFMT and PIDF contain content that an end user might want to encrypt and
conceal from a gateway, but that isn't true of response operations. I agree
that it is not 'the same assurance', but it can still be secure.

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



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