RE: subscription identifiers

Thanks for these useful notes on the subscription operation.

Just to be clear, at the moment I do not believe that we need to define a
tunneled subscription object - following Mr. Rosenberg's suggestion, I
believe we should only use tunneled objects when we need to apply end-to-end
security properties to attributes described by CPIM. So far, our thinking
about subscriptions has necessitated authentication/authorization properties
(which can be addressed with transitive, hop-by-hop security), but not any
integrity or confidentiality properties that would require S/MIME or some
similar mechanism.

Some notes on your section 2 text inline below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Thursday, September 12, 2002 6:39 AM
> To: [email protected]
> Cc: [email protected]
> Subject: subscription identifiers
> 
> 
> Jon,
> 
> I've updated the content of 
> 
>    http://simp.mitre.org/drafts/sdf.txt
> 
> I've changed the description of the subscribe operation in the
> document.  I offer the description as proposed text for specifying
> subscription identifiers in CPIM when they become separated from
> transaction identifiers.
> 
> Additionally, following the results of the discussion on the
> notification operation, in which no wrapper appears to be needed, the
> CPIM Subscription Data Format document specifies the use of XML syntax
> for the content that can be signed.
> 
> John
> 
> 2. The SUBSCRIBE Operation
> 
> The SUBSCRIBE operation is used to request that a service deliver PRES­
> ENCE INFORMATION as specified in [CPIM].  As a side effect of a success­
> ful SUBSCRIBE request, a PRESENCE SERVICE MUST initiate a NOTIFY request
> that delivers the current PRESENCE INFORMATION contained by the PRESEN­
> TITY targeted by the SUBSCRIBE request.
> 
> If the SUBSCRIBE request specifies a non-zero subscription duration, a
> successful response MUST include the duration of the SUBSCRIPTION
> granted by the service.  

This could apply to zero duration subscriptions as well.

> If the SUBSCRIBE request does not contain an
> identifier, the PRESENCE SERVICE must return an identifier for the sub­
> scription as part of a successful response.  

As I said in a separate mail, I think we'd need to understand the motivation
for this feature, since it does seem to introduce some complexity.

> As long as the SUBSCRIPTION
> has not lapsed, when the PRESENCE INFORMATION changes, the PRESENCE SER­
> VICE MUST initiate a NOTIFY request that delivers the new PRESENCE
> INFORMATION to the SUBSCRIBER.
> 
> The triple consisting of an identifier, and the names of a WATCHER, and
> a PRESENTITY uniquely identify a SUBSCRIPTION.
> 

Might want to be explicit that you mean a 'subscription identifier' here.

> A SUBSCRIPTION can be canceled with a SUBSCRIBE request that specifies
> the SUBSCRIPTION's identifier and a duration of zero seconds.  A SUB­
> SCRIBER cannot hold more than one SUBSCRIPTION.

I thought part of the purpose of a subscription identifier was to allow a
subscriber to hold multiple subscriptions to the same presentity.

This section should also mention that a notification is sent when an
unsubscribe operation is performed.

> A PRESENCE SERVICE MUST
> cancel a SUBSCRIPTION from a SUBSCRIBER when that SUBSCRIBER issues a
> SUBSCRIBE request with a non-zero duration that does not contain the
> original SUBSCRIPTION's identifier.
> 
> PRESENCE INFORMATION can always be fetched by issuing a SUBSCRIBE
> request with a zero duration and no subscription identifier.

Alternatively, this could contain any previously unused subscription
identifier and a zero duration. Any reason to prefer your proposal?

> If a SUB­
> SCRIBE request specifies a zero subscription duration, a successful
> response MUST NOT contain any duration information.
> 

... might be better to be explicit, and say that the duration is zero. That
way we don't need to have a special case for zero-duration subscription
behavior.



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