Protocol Action: 'Common Profile for Instant Messaging (CPIM)' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved following documents:

- 'Common Presence and Instant Messaging: Message Format '
   <draft-ietf-impp-cpim-msgfmt-08.txt> as a Proposed Standard
- 'Presence Information Data Format (PIDF) '
   <draft-ietf-impp-cpim-pidf-08.txt> as a Proposed Standard
- 'Common Profile for Presence (CPP) '
   <draft-ietf-impp-pres-03.txt> as a Proposed Standard
- 'Common Profile for Instant Messaging (CPIM) '
   <draft-ietf-impp-im-03.txt> as a Proposed Standard
- 'Address Resolution for Instant Messaging and Presence '
   <draft-ietf-impp-srv-03.txt> as a Proposed Standard

These documents are products of the Instant Messaging and Presence Protocol 
Working Group. 

The IESG contact persons are Ted Hardie and Ned Freed.

Technical Summary

These documents form the basis for a mechanism by which multiple
distinct Instant Messaging applications may pass messages among
the different systems while retaining the ability to use end-to-end
encryption, integrity protection, and a shared framework for presence
information.
The work on PIDF (Presence Information Data Format) is already in
widespread usage by the SIP-based instant messaging community,
as is the message format described.

Working Group Summary

The IMPP working group was originally chartered to develop requirements
and then protocols which would provide an "Internet-scale end-user
presence awareness, notification and instant messaging system". The group
delivered RFCs 2778 and 2779 defining a model and requirements for
instant messaging, but it was unable to select among the candidate
protocols for this task even after setting up a nine-member design
and review team. After this impasse was reached, the work of
development was split to allow for multiple, interoperable transport 
protocols.
While the tasks assigned to those groups chartered after the split
are relatively clear in their charters, the work to be done by IMPP
was, regrettably, not defined in a new charter. As a result, the
task taken on by these documents represents the rough consensus
of the group as determined by the chairs; there remains, however,
a view that the group was chartered to define minimal gateway
semantics for the multiple IM systems, thus rendering end-to-end
encryption and data integrity out of scope, rather than the formats
and framework defined by these documents.

In evaluating these documents, the IESG has thus both needed to assess
whether the documents meet the needs of the work plan as the chairs
have understood it and whether the work plan itself was on target. The
IESG greatly regrets the necessity of this second task and its failure in
not updating the charter of IMPP. It does not, however, believe that refusin

to advance the documents on the basis of this failure is appropriate,
as it is contrary to the promotion of interoperability in this arena. 
Instead,
the IESG has been guided by the charters granted to the successor groups,
by the place end-to-end security normally holds in IETF protocol
analyses, and by a careful review of the mailing list and minutes of the
meetings subsequent to the split. The IESG has, through this review,
concluded that the work plan described by the chairs was on target
and has conducted their technical review of the documents solely on
the question of whether the documents meet the need outlined by that plan.

In its technical evaluation, the IESG noted that many of the formats and
discovery mechanisms described are already in use or replicate well-known
existing mechanism. They reflect that maturity in their description
and completeness. The core document on CPIM, in contrast, represents a fairl
abstract description of the service. The IESG believes that the documents ar
of sufficient quality to be the basis of an interoperable service, but notes 
that it expects the development of documents mapping CPIM to specific 
protocols to show how to make the abstract terms in CPIM concrete. Further, 
it expects that
interoperability reports presented for the transition to draft standard woul
include multiple protocols, as well as the usual requirement that the 
implementations be independent.

Protocol Quality

The documents were reviewed for the IESG by Ted Hardie.


Dear RFC-Editor:

Please make the following changes in draft-ietf-impp-cpim-msgfmt-08.txt

                                thanks,
                                                                Ted Hardie

Section 3.6

OLD:

                                      ; Any US-ASCII char except ".", CTLs o
SEPARATORS:
            NAMECHAR = %21 / %23-27 / %2a-2b / %2d / %5e-60 / %7c / %7e
                                      / ALPHA / DIGIT

NEW:

                                      ; Any US-ASCII char except ".", CTLs o
SEPARATORS:
            NAMECHAR = %x21 / %x23-27 / %x2a-2b / %x2d / %x5e-60 / %x7c / 
%x7e
                                      / ALPHA / DIGIT


OLD:


            SEPARATORS = "(" / ")" / "<" / ">" / "@" ; 28/29/3c/3e/40
                         / "," / ";" / ":" / "" / <"> ; 2c/3b/3a/5c/22
                         / "/" / "[" / "]" / "?" / "=" ; 2f/5b/5d/3f/3d
                         / "{" / "}" / SP ; 7b/7d/20

NEW:


            SEPARATORS = "(" / ")" / "<" / ">" / "@" ; 28/29/3c/3e/40
                         / "," / ";" / ":" / "" / %x22 ; 2c/3b/3a/5c/22
                         / "/" / "[" / "]" / "?" / "=" ; 2f/5b/5d/3f/3d
                         / "{" / "}" / SP ; 7b/7d/20



OLD:
            From-header = "From" ": " [ Formal-name ] "<" URI ">"

NEW:
            From-header = "From" ": " [ Formal-name ] "<" URI ">"
                                  ; "From" is case-sensitive

OLD:
            To-header = "To" ": " [ Formal-name ] "<" URI ">"

NEW:
            To-header = "To" ": " [ Formal-name ] "<" URI ">"
                                      ; "To" is case-sensitive

OLD:
            Cc-header = "cc" ": " [ Formal-name ] "<" URI ">"

NEW:
            Cc-header = "cc" ": " [ Formal-name ] "<" URI ">"
                                   ; "cc" is case-sensitive

OLD:
            DateTime-header = "DateTime" ": " date-time

NEW:
            DateTime-header = "DateTime" ": " date-time
                              ; "DateTime" is case-sensitive

OLD:
            Subject-header = "Subject" ":" [ ";" lang-param ] SP *HEADERCHAR

NEW:
            Subject-header = "Subject" ":" [ ";" lang-param ] SP *HEADERCHAR
                                        ; "Subject" is case-sensitive


OLD:
            NS-header = "NS" ": " [ Name-prefix ] "<" URI ">"

NEW:
            NS-header = "NS" ": " [ Name-prefix ] "<" URI ">"
                                         ; "NS" is case-sensitive

OLD:
            Require-header = "Require" ": " Header-name *( "," Header-name )

NEW:
            Require-header = "Require" ": " Header-name *( "," Header-name )
                                        ; "Require" is case-sensitive


Section 4.5:

OLD:

            Subject-header = "Subject" ":" [ ";" lang-param ] SP *HEADERCHAR

NEW:

            Subject-header = "Subject" ":" [ ";" Lang-param ] SP *HEADERCHAR