Subject: Re: Content-Length header and Multipart MIME

From: [email-masked]
Date: Thu, 27 Jan 2000 10:42:30 +0530

Hi Adam,
I had read this section, and it confuses me a bit.
If this section mentions a MUST then its mandatory that _all_ applications
must append a CRLF only.
Then what is the use for parsing incoming messages for CR, LF or CRLF ?
I guess it would make sense only if there is a possibility that some
application may send only a CR or an LF.
Then the receiver can be lenient on this input. (ie if 6.6 was a SHOULD)

However, if  6.6 states it as a MUST, which implies that a person who sends
CR orLF only is not SIP compliant.
then where is the question of the receiver expecting anything else - and if
it does, it should not accept it as the sender
violated a mandatory clause of the protocol.

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

"Adam B. Roach" <[email-masked]> on 01/25/2000 08:30:50 PM

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

Subject:  Re: Content-Length header and Multipart MIME

[email-masked] writes:
>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 ?

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

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 27 Jan 2000 09:13:11 -0600 (CST)

>violated a mandatory clause of the protocol.

It's one of the overarching philosophies of IETF protocols:
be strict in what you generate, but lenient in what you accept.
That way, for two implementations of a protocol to be
non-interoperable, they must *both* be broken.

This is one of the reasons occasionally cited why IETF protocols
tend to interoperate more sucessfully than those of other
standards bodies.