Subject: RE: [Sip] ABNF issue

From: "Rob Phillips" <[email-masked]>
Date: Wed, 11 Dec 2002 05:31:21 -0600

I would argue that the grammar is not ambiguous when taken in context.  Refer the ABNF and text in section 7:

         generic-message  =  start-line
                             *message-header
                             CRLF
                             [ message-body ]
         start-line       =  Request-Line / Status-Line

   The start-line, each message-header line, and the empty line MUST be
   terminated by a carriage-return line-feed sequence (CRLF).  Note that
   the empty line MUST be present even if the message-body is not.

As has been shown before, you can't always take the ABNF in a vacuum - the context found in the rest of the RFC can often narrow what's allowed by the protocol, even when the ABNF says it's "legal".

- rob

--
Rob Phillips, Sr. Software Engineer                 Netrake Corporation
mailto: [email-masked]                           3000 Technology Drive
voice: (214) 291-1096                                         Suite 100
fax:   (214) 291-1010     http://www.netrake.com     Plano, Texas 75074
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Dec 2002 13:50:46 +0200

Hi Rob,

>    the empty line MUST be present even if the message-body is not.

Yes.

> As has been shown before, you can't always take the ABNF in a vacuum - the context found in the rest of the RFC can often narrow what's allowed by the protocol, even when the ABNF says it's "legal".

I FULLY agree. But, in those cases you have to specify the things in the spec. Now the spec only says that the SIP part of the message ends with CRLF, and that is not the issue. IF the spec would
"narrow" the ABNF rules by saying that the definition of LWS is not valid in the beginning of a new line, OR if the spec would define the CRLFCRLF token, we would not have this problem.

Regards,

Christer Holmberg
Ericsson Finland