Re: Comments on CPIM draft 03

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

> I agree that the way the 'operations' in the core CPIM spec are currently
> specified, it isn't clear if they are intended to ....

Of course, rather than abolishing transaction IDs for request/response
matching, another alternative is to add text making in very clear the
intended role of the IDs in the specification by, for example, making
it clear protocols don't actually have to have transaction
IDs--concrete protocols must just implement the semantics implied by
them.

If transaction IDs are only for matching requests to replies, its
still not clear to me why the notification operation has them.

On the topic of subscription IDs, I note the change I suggested which
used transaction IDs as subscription IDs had two flaws (at least).
One was that transaction IDs were being used for two logically
distinct purposes, and another one is that presence user agents
generated subscription IDs.  With this design, a CPIM compliant
protocol could not use the convention that subscription IDs are
generated by a presence service.  In other words, one cannot have the
case in which a client requests a subscription, and receives the ID in
the response.  Is it our intension to require that only presence user
agents select subscription IDs?

John





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