subscription token

It occurs to me there is a simple way to avoid the confusion
surrounding the fact that a subscription identifier does not, in
itself, identify a subscription.  Why not simply call it a
subscription token?  The term token does not imply too much about its
function.  One could also replace the term 'transaction ID' with
transaction token, and thereby making it clear it is not sufficient to
identify a transaction.

After adopting the token term and responding to Jon Peterson's
comments, section two of the Subcription Data Format document reads:

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, except when the operation can­
cels a SUBSCRIPTION.

A successful response to a SUBSCRIBE operation MUST include the duration
of the SUBSCRIPTION granted by the service.  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 a token, and the names of a WATCHER, and a PRE­
SENTITY uniquely identify a SUBSCRIPTION.  If the SUBSCRIBE request
specifies a non-zero subscription duration, it must contain a SUBSCRIP­
TION token.  A SUBSCRIPTION can be canceled with a SUBSCRIBE request
that specifies the SUBSCRIPTION's token and a duration of zero seconds.

PRESENCE INFORMATION can always be fetched by issuing a SUBSCRIBE
request with a zero duration and no token.

John



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