Message-Id: <200209231937.PAA21936@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@iab.org>,
   sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Date: Mon, 23 Sep 2002 15:37:59 -0400
Subject: [Sip] Protocol Action: Message/sipfrag to Proposed Standard
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
Precedence: bulk


The IESG has approved publication of the following Internet-Draft as 
a Proposed Standard:

o Internet Media Types message/sipfrag 
<draft-ietf-sip-sipfrag-00.txt>

This document is a product of the Session Initiation Protocol 
Working Group. The IESG contact persons are Allison Mankin and 
Scott Bradner.

Technical Summary

The spec registers the message/sipfrag MIME media type. This 
type is similar to message/sip, but allows certain subsets of well 
formed SIP messages to be represented instead of requiring a complete 
SIP message. In addition to end-to-end security uses, message/ 
sipfrag is used with the REFER method to convey information about the 
status of a referenced request. The message/sipfrag is used with 
S/MIME for gaining integrity and other security services. Advice 
is given for anti-replay and reference integrity when used. The 
type is not analogous to message/partial.

Working Group Summary 

The working group had excellent consensus on this document. 
NOTE: the document was Last Called along with draft-ietf-sip- 
refer under another its original internet-draft name of 
draft-sparks-sip-mimetypes. 

Changes to the document represent responses to the Last Call 
and IESG comments and improved clarity, security, anti-replay, 
protection, reference integrity. 

Protocol Quality 

The specification was reviewed for the IESG by Allison Mankin. 
Last Call comments by the IESG on sipfrag resulted in considerable 
clarification of the document.


Note to RFC Editor:

Please insert the following just before section 2:

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
    "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
    and "OPTIONAL" in this document are to be interpreted as 
    described in [RFC 2119].

and add the following to the normative references

   [RFC2119] Bradner, S., "Key words for use in RFCs to 	
   Indicate Requirement Levels.", RFC 2119, March 1997


Also, please make the following reference correction:

Old:

      The concepts in that section can be extended to allow SIP entities to
      make assertions about a subset of a SIP message (for example, as
      described in [3]).

New:
      The concepts in that section can be extended to allow SIP entities to
      make assertions about a subset of a SIP message (for example, as
      described in [4]).

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip