[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: Protocol Action: 'Common Profile for Instant Messaging (CPIM)' to Proposed Standard
I believe we need to send out a new announcement here, as
the document version numbers are wrong. I'm afraid I may
have assumed that this would automatically pick up the new
versions, and I did not mark that change. My apologies if
I should have done so. There are, however, -04 versions of
all the ones listed as -03 below (-pres, -im, and -srv).
This also seems to have cut the last letter on some lines.
I've indicated the missing letters below.
Ted
>X-test-idtracker: no
>From: The IESG <iesg-secretary@ietf.org>
>To: IETF-Announce:;
>Cc: Internet Architecture Board <iab@iab.org>,
> RFC Editor <rfc-editor@rfc-editor.org>, <impp@iastate.edu>
>Subject: Protocol Action: 'Common Profile for Instant Messaging
> (CPIM)' to Proposed Standard
>Date: Wed, 29 Oct 2003 14:54:42 -0500
>Sender: owner-ietf-announce@ietf.org
>
>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
refusin-->refusing
>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
woul-->would
>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