Cisco Systems

170 West Tasman Drive MS: SJC-21/3 San Jose CA 95134 USA +1 408 527-9132 fluffy@cisco.com

Transport SIP WG I-D Internet-Draft Mime This document describes conventions for using MIME body parts in SIP messages. It uses a transport encoding of "binary" since SIP messages are always passed over an 8bit clean transport.

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. This document adopts the terminology defined in RFC 2045, particularly for the terms "transport encoding" and "binary".

The Session Initiation Protocol (SIP) protocol makes use of MIME body parts. MIME provides several alternatives that were required given the characteristics of existing mail transport protocols and mail gateways that MIME operates through. SIP is always transported over an 8bit safe transport and thus does not need all the options available. This draft clarifies what should be used in the SIP context.

MIME offers several transport encoding options and any of them will work in SIP. However, having several options where one is needed does not contribute to interoperability. Binary encoding is faster to encode and decode, requires less code, and results in smaller messages than the other options. There has been a practice in the published SIP examples of using a base64 encoding due to the ease of displaying the example in publication. Some SIP implementers have taken this to mean that this is the preferred encoding and as a result only work with base64. Given the need to improve interoperability, it is reasonable to suggest that SIP implementations send one type of encoding. There are situations in which the body from a SIP message might be passed to another non SIP transport that might expose additional limitations. Currently the only example of this is the transfer of bodies from instant messaging messages to other instant messaging systems. Since other instant messaging protocols are also 8bit clean, gateways from SIP instant messaging to these other protocols do not have this problem. Gateways to other protocols (for example SMTP) need to modify the content of these messages anyway, regardless of the MIME encoding which is used on the original message.

Devices MUST use a content transfer encoding of "binary" for MIME body parts in SIP messages they send.

This document limits options that exist in RFC 3261 so it does not introduce any additional security concerns beyond what is in RFC 3261.

Should we bother to do this or just write it up as a bug on RFC 3261?

Innosoft International, Inc.

1050 East Garvey Avenue South West Covina CA 91790 US +1 818 919 3600 +1 818 919 3614 ned@innosoft.com

First Virtual Holdings

25 Washington Avenue Morristown NJ 07960 US +1 201 540 8967 +1 201 993 3032 nsb@nsb.fv.com

STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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. Note that the force of these words is modified by the requirement level of the document in which they are used.