Subject: RE: Content-Length header and Multipart MIME

From: [email-masked]
Date: Wed, 19 Jan 2000 14:24:57 -0700

Hello,

First off, the LATEST version of the SIP-BCP-T (or SIP-T) as it will
be known henceforth is available at:
http://www.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt

This draft contains a corrected example.

About the Content-Length calculation - it is as explained below:

This is the example that is used in the SIP-T draft. The number of
 octets used in each line are shown at the end of each line in parentheses.

	INVITE sip:[email-masked] SIP/2.0
	From: sip:[email-masked]
	To: sip:[email-masked]
	Call-ID: [email-masked]
	Content-Length: 377
	Content-Type: multipart/mixed; boundary=unique-boundary-1
                MIME-Version: 1.0
	
	--unique-boundary-1(19)
	Content-Type: application/SDP; charset=ISO-10646(49)

                v=0(3)
	o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4(52)
	s=SDP seminar(13)
   	c=IN IP4 MG122.level3.com(25)
	t=2873397496 2873404696(23)
	m=audio 9092 RTP/AVP 0 3 4(26)

	--unique-boundary-1(19)
	Content-type:application/ISUP;version=ETSI1(44)
	Content-Transfer-Encoding: binary(34)

	89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00(17)
	--unique-boundary-1--(21)

b)  Rules used to calculate the Content-Length:
     b.1 Use 2 octets to encode the CRLF sequence at the end of each line
           and the beginning of a blank line.
     b.2 For the MIME headers in the payloads: each character maps onto one
octet.
     b.3 For the SDP payload: each character maps onto one octet according
             to UTF-8 encoding (RFC 2044) used as specified in the SIP-BCP.
     b.4 For the ISUP payload: Since binary encoding is used, each byte is
encoded
             as a byte, and not as a  two-character hex representation.  Hex
digits were
             used in the draft because a literal encoding of those bytes
would have been
             confusing and unreadable.

c) Content-Length calculation:
     c.1 Number of octets in the ISUP payload (no CRLF at the end since it
is 
            binary)
            = 17
     c.2 Number of octets in the MIME header for the ISUP payload (including
            the CRLF at the end of each line)
            = 46+ 36
            = 82
     c.3 Number of octets in the SDP payload (including the CRLFs at the end
            of each of the lines)
            = 5 + 54 + 15 + 27 + 25 + 28
            = 154
     c.4 Number of octets in the MIME header for the SDP payload (including
            the CRLF at the end of the line)
            =51
     c.5 Number of octets in the '--unique-boundary-1' string and newlines
            used throughout:
             = 21 + 21 + 23 + 4*2 = 73
     c.6 The grand-total
             = 17 + 82 +154 + 51 + 73  = 377

Thanks,
Aparna
Level (3) Communications.

-----Original Message-----
From: Igor Slepchin [mailto:[email-masked]]
Sent: Wednesday, January 19, 2000 10:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Content-Length header and Multipart MIME

[email-masked] wrote:
> 
> Hi
>      When a SIP message carries a multipart MIME payload, what does the
> Content-Length header in the SIP message signify ? Does it contain the
> overall length of the payload ? Though it seems logical that it should

I believe that's correct. Content-Length has a uniform meaning
regardless of the type of the payload, namely, the total length of that
payload. The example you quote seem to have a totally random value of
Content-Length. BTW, there is another problem in that example: the SIP
message shown contains two Content-Type fields.

> <...>

---
Igor Slepchin

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Jan 2000 21:08:46 -0500

> http://www.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt

Is it really necessary to label some simple additions to SIP with a new
name? We've had the SIP+ disaster before (in terms of confusion) and I'd
rather not repeat this.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Jan 2000 00:18:14 -0500

First off, its important to mention what has happened regarding SIP-T
within IETF. As you may recall, consensus during the last meeting was
that people were interested in having the SIP-T work complete in IETF.
However, there wasn't a final decision on what working group, and what
specific documents would be produced. The chairs of the SIP group
discussed this with the ADs, and we agreed this work is best handled
within the SIP working group. Furthermore, several documents would be
produced:

1. SIP INFO (already a work item; in fact, an update should appear in
the archives shortly, and I will be issuing a last call on it)
2. ISUP MIME type RFC (proposed standard)
3. ISUP to SIP interworking RFC (proposed standard)
4. SIP profile for this application (currently named SIP-T): proposed

As for the name, since I think we will do proposed standard for it,
SIP-BCP-T is inappropriate. If people have suggestions for alternative
names to SIP-T, we can entertain them (we changed GLP to TRIP at the
last minute in iptel...)

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com