Subject: [Sip] Protocol Action: Session Initiation Protocol Extension for Instant Messaging to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 20 Sep 2002 17:01:32 -0400

The IESG has approved the Internet-Draft 'Session Initiation Protocol
Extension for Instant Messaging' <draft-ietf-sip-message-07.txt> as a
Proposed Standard.  This document is the product of the Session
Initiation Protocol Working Group.  The IESG contact persons are
Allison Mankin and Scott Bradner.

Technical Summary
 
  RFC 2778 and RFC 2779 give a model and requirements for presence
  and instant messaging protocols. The Session Initiation Protocol
  (RFC 3261) provides mechanisms that are useful for presence
  applicatons, and for session-oriented communication applications.
  This document specifies a new method for SIP called MESSAGE, which
  adds an instant message mechanism as well, fulfilling
  RFC 2779. This IM mechanism is intended for pager style use,
  in which a MESSAGE carries a short text, or message/cpim body,
  as a stand-alone communication, rather than a stream of connected
  data, in a "session mode." The SIMPLE working group is currently
  working to understand the session model more fully and determine
  how SIMPLE should best support it (for instance with multiple
  types of session modes).
   
Working Group Summary
   
  The requirements for this specification originated in the
  IMPP and SIMPLE Working Groups, and then the protocol
  extension was completed by SIP. The major point of contention
  was to ensure that MESSAGE did not become a congestion-prone
  transport-replacement, taking advantage of SIP's original ability
  to run over UDP. Fortunately, beginning with RFC 3261, any SIP
  message with a large payload is likely to use TCP for its transport.
  The MESSAGE specification achieved strong working group and
  Transport area consensus after vigorous discussion of its first
  few revisions.

Protocol Quality
   
    Allison Mankin reviewed the specification for the IESG.
    Several early commercial implementations have been identified.

Note to RFC Editor:

Please make the following changes:

Before the Introduction, add an unnumbered section -

Terminology

      In this document, the key words "MUST", "MUST NOT", "REQUIRED",
      "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
      RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
      described in BCP 14, RFC 2119 and indicate requirement levels for
      compliant SIP implementations.

-------
References

Add RFC 2119 to Normative references.

-------

11. Security Considerations

Old:

      In particular, UAs that
      support the MESSAGE request SHOULD support end-to-end authentication,
      body integrity, and body confidentiality mechanisms.
New:

      In particular, UAs that
      support the MESSAGE request MUST implement end-to-end authentication,
      body integrity, and body confidentiality mechanisms.

------
11.1 Outbound authentication

Old:
      When local proxies are used for transmission of outbound messages,
      proxy authentication is RECOMMENDED. This is useful to verify the
      identity of the originator, and prevent spoofing and spamming at the
      originating network.

New:
      When local proxies are used for transmission of outbound messages,
      proxy authentication, as specified in RFC 3261, is RECOMMENDED. 
      This is useful to verify the identity of the originator, and prevent
      spoofing and spamming at the originating network.

------
11.3 End-to-End Protection

Old:
      To alleviate the concerns stated above, the MESSAGE bodies SHOULD be
      secured with S/MIME.

New:

      For remedying the concerns stated above, the MESSAGE bodies
      MUST be secured with S/MIME. If bodies specified in future to be
      carried by the MESSAGE method have different means of providing
      end-to-end security, their specification MUST describe the usage.
-------

11.4 Replay Prevention

OLD:
   To prevent the replay of old SIP requests, all signed MESSAGE
   requests and responses SHOULD contain a Date header field covered by
   the message signature.

NEW:

   To prevent the replay of old SIP requests, all signed MESSAGE
   requests and responses MUST contain a Date header field covered by
   the message signature.
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Tan Ya-Ching ICM N PG U ID A 1 <[email-masked]>
Date: Mon, 23 Sep 2002 10:03:16 +0200

| -----Original Message-----
| From: The IESG [mailto:[email-masked]]
| Sent: 20 September 2002 23:02
| Cc: RFC Editor; Internet Architecture Board; [email-masked]
| Subject: [Sip] Protocol Action: Session Initiation Protocol Extension
| for Instant Messaging to Proposed Standard
| 
| 
| 
| 
| The IESG has approved the Internet-Draft 'Session Initiation Protocol
| Extension for Instant Messaging' <draft-ietf-sip-message-07.txt> as a
| Proposed Standard.  This document is the product of the Session
| Initiation Protocol Working Group.  The IESG contact persons are
| Allison Mankin and Scott Bradner.
| 

Note to RFC Editor,

Table 1 and Table 2 of draft-ietf-sip-message-07 seem to be based on the
older version of SIP RFC.  Table 1 and Table 2 of RFC 3261 have the
following headers which are missing in the 07 draft :

Min-Expires
MIME-Version
Supported

Regards,
Ya-Ching Tan

---

From: [email-masked]
Date: Mon, 23 Sep 2002 09:39:44 -0700 (PDT)

Tan,

Thank you for bringing this to our attention.  If this is correct, the
authors will have the opportunity to correct this during the "authors
48 hours" period.

Thank you.

RFC Editor

> From: Tan Ya-Ching  ICM N PG U ID A 1 <[email-masked]>
> To: RFC Editor <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [Sip] Protocol Action: Session Initiation Protocol Extension  for 
Instant Messaging to Proposed Standard
> Date: Mon, 23 Sep 2002 10:03:16 +0200
> MIME-Version: 1.0
> 
> 
>