Re: subscription identifiers

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

> Some notes on your section 2 text inline below.

The purpose of submitting Section 2 to this group was to use it to
help us reach consensus on issues surrounding subscription
identifiers.  I'm not attached to the details in the text.

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

Okay by me.

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

The only reason I asked people to think about this issue is that the
SIMP protocol works this way.  Since the SIMP protocol will never be
CPIM-compliant, I cannot lobby for this feature, but I do ask people
be aware that the current protocol only allows client to generate
identifiers.  That being said, I'll drop this idea unless someone else
expresses interest.

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

In the text I wrote, I was carefully avoiding calling the identifier a
subscription identifier, because it does not identify a SUBSCRIPTION.
Only the triple of consisting of an identifier, and the names of a
WATCHER, and a PRESENTITY uniquely identify a SUBSCRIPTION.  I found
this point confusing in the CPIM draft, and Thanos clarified it.  I
hope the text in CPIM will be careful about this point.

> > 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 requirement also seems bogus to me, but I picked it up from 
language in an old draft somewhere.  I think it should be omitted as
you suggest.

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

Is that a requirement?  If one is canceling a subscription, aren't you
saying you don't want further notifications?  We should decide.

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

Oh, yeah, I forgot about this.  The idea is that the components of a
client requesting a fetch should not need to keep track of, and know
about what identifiers are in use by other parts of the client.

John



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