Subject: RE: Content-Length header and Multipart MIME

From: [email-masked]
Date: Tue, 25 Jan 2000 12:00:17 +0530

Hi,
I have a question regarding the computation of Content-Length you
mentioned.

Aparna> Rules used to calculate the Content-Length:
Aparna> b.1 Use 2 octets to encode the CRLF sequence at the end of each
line
Aparna> and the beginning of a blank line.

Does in necessarily have to be two octets ? the sip grammar defines the
separator as
CR | LF | CRLF depending on the target system's interpretation of a new
line.

So isnt't it that whether 1 or 2 octets for end-of-line is taken for C-Len
should vary
depending on what is the line separator one is using ?

Regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems

[email-masked] on 01/20/2000 02:54:57 AM

To:   [email-masked], K Binu/HSSBLR
cc:   [email-masked]

Subject:  RE: Content-Length header and Multipart MIME

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: "Adam B. Roach" <[email-masked]>
Date: Tue, 25 Jan 2000 09:00:50 -0600 (CST)

>depending on what is the line separator one is using ?

The "CR | LF | CRLF" is for parsing of messages. In RFC2543, sec 6.6,
it says that "applications MUST follow HTTP common form when generating
[headers]." This denotes a full CRLF at the end of each line.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA