CPIM changes

A number of changes have been introduced to the new CPIM drafts based on
recent discussions in the mailing list.

Firstly, the DTDs have been removed. The abstract syntax for IM and Presence
operations was, in my opinion, very heavy (and led to misunderstandings that
this XML format could be used to create tunneled objects that would be
carried by protocols using these operations) - I have replaced the DTDs with
a simple listing of 'attributes' associated with each operation. Some text
that helps readers to understand the concepts of operations and attributes
is now given in the Terminology section.

Secondly, the draft now contains text that describes how the operations of
the services are related to MSGFMT and PIDF. These two 'formats' for IM and
Presence information are provided as a means to achieve end-to-end
properties (most notably security) between the protocols interworking
through a gateway. If a protocol does not support these formats, then
end-to-end security through a gateway will not be possible. The current text
of the draft states that MSGFMT and PIDF SHOULD be supported by IM&P
protocols (respectively). Specific security requirements for the use of
MSGFMT and PIDF (i.e. S/MIME, etc) do not appear in the CPIM drafts - these
security guidelines will appear in the MSGFMT and PIDF drafts themselves.

Thirdly, draft-ietf-impp-pres-00 now contains the concept of a subscription
ID. Unfortunately, looking at the text of draft-ietf-impp-pres-00, 3.4.3
contains a error - the SubscriptID should be used in an unsubscribe
operation, not the TransID, to identify the subscription to which one is
unsubscribing - this will be corrected in a subsequent revision. A
unsubscribe operation, which is in fact a subscribe operation with duration
0, uses a new TransID, just like any other new subscribe operation. In any
event, that is the intended usage of the SubscriptID parameter in the
document.

Numerous other minor bugfixes have been made. The Introductions and Security
Considerations were substantially rewritten to provide stronger context for
this work.

Two real open issues of substance remains:

draft-ietf-impp-im-00 has a concept of a hop-count that is used for loop
detection. Obviously, when a gateway interworks two IM protocols, loop
detection is a very difficult quality to achieve, since we cannot guarantee
that any given mechanism for loop detection (such as a ttl-like decrementing
integer attribute vs. a Received-header-like way for servers to tell that a
message has reached them before) will be used by an IM protocol. So, the
text in the current document says that gateways should if possible gateway
between mechanisms used for loop detection, but loop detection itself is not
specified as an attribute for the messaging operation. Is that all right
with everyone?

draft-ietf-impp-pres-00 specifies that notify operations have a TransID.
However, since no response operation for notify is defined, TransID seems
useless in this context. There has been some speculation that notify
operations might want to have some sort of CPIM-layer response, but to date
no need for this has been clearly articulated (CPIM should not be defining
operations/attributes purely for reliable message delivery, anyway).
However, in a case in which a watcher has multiple subscriptions to the same
presentity, it could be useful to know which subscription has generated a
notification. Therefore, it seems that the notify operation should perhaps
contain a SubscriptID, not a TransID. Any thoughts about this proposal?

Jon Peterson
NeuStar, Inc.



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