draft-ietf-impp-cpim-03

Hello all,

Well, last week after some confusion we finally managed to complete the
transition of editorship of the CPIM document to me, and as promised, I've
provided a new version of the CPIM draft. So, at the very least, we have a
CPIM document in the repository.

The draft incorporates fixes for the initial comments that were given in the
CPIM issues summary given on the list in June, including:

- The definition of the IM and PRES URI schemes is now given only in the
Appendices; all earlier sections (including the IANA considerations) should
now reference that section. Formerly, there were a number of confusing and
contradictory definitions provided in the draft (most of which were vague
allusions to following RFC822/2822).

- Section 8 now no longer contains XML syntax for an UNSUBSCRIBE command.
Following 3.4.3, UNSUBSCRIBE is defined as a SUBSCRIBE operation with a
duration of 0.

- I have tried to address Mr. Klyne's comments, which included editorial
fixes, reference updates, and a suggested profile to populate Appendix A.

- At (as Mark is fond of saying) Sugano-san's request, the 'profile'
parameter has been removed from the 'message/cpim' MIME type descriptions in
Sections 2.3 and 3.3. 

Given that these defects have been improved, if not resolved, there are
other matters that require our consideration in this document, namely:

- Security. Currently, although the assessment of threats is quite detailed,
the draft is quite short on any security recommendations. Simply saying
"either S/MIME or OpenPGP should work" most likely will not be sufficient;
for interoperability's sake we will need to pick a winner, I think. I
recommend that we choose S/MIME, and we give it an appropriate requirements
strength (deriving probably from the normative language of RFC2778/RFC2779).
I also believe we need to name a minimum ciphersuite that is mandatory to
implement for implementers of the security scheme.

- Organizationally, I think this draft needs to be compared with the MSGFMT
and PIDF documents in order to weed out some overlaps. Ultimately, I think
the purpose of the main CPIM doc should be to provide a framework for CPIM
(citing MSGFMT and PIDF when possible) as well as to register and detail the
IM and PRES URI schemes. Examples that follow those drafts should, no doubt,
be updated to reflect the current state of those drafts. Also, the URI
dereferencing system described in the IM section (2.2) should probably be
split out into an independent section and generalized so that the reference
from the Presence section (3.2) does not point to a section filled with
language and examples about IM.

- I think the purpose of the DTDs (sections 6, 7, 8 and 9) in the draft is a
little obscure, and that they could use some more motivation/explanation if
they are to remain. Should some or all of these be provided elsewhere (in
MSGFMT or PIDF)? Process-wise, I also seem to recall hearing that placing
DTDs in RFCs was now discouraged...

- Appendix B is still empty - we need to fill it with a suitable profile for
Presence services. Why CPIM needs to profile Presence & IM messages
(defining required headers, and so on) rather than relying on the respective
MSGFMT and PIDF drafts to fulfill this function is another question worth
exploring. 

- Some internal references in the draft still need to be redone (after a
format change).

- There are also a few straggling issues from the list, like those related
to security of subscriptions/notifies, presence service identification, and
so on, which I don't know if we have resolved or not. More to come on those.

In any event, I welcome review of the changes introduced between -02 and
-03, as well as comment on the issues raised in this mail. Let's get this
draft done!

Jon Peterson
NeuStar, Inc.



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