Subject: SIP ABNF Problem?

From: "Buller, Jim" <[email-masked]>
Date: Fri, 31 Jul 1998 15:28:26 +0100

Ladies and Gentlemen,

I am presently working through your document, "draft-ietf-mmusic-sip-07
- SIP: Session 
Initiation Protocol", as part of a PINT implementation I have just
started undertaking. I 
have found what I believe may be a couple of problems/ errors concerning
some of 
your ABNF definitions. I bring them to your attention as requested in
the Abstract as
you may wish to investigate them further.

Page 19.
=======
Paragraph beginning, "Both Request (section 4) and Response (section
5)", states that :

     "Both types of message consist of a start-line, one or more header 
     fields(also known as 'headers'), an empty line..... " etc

I therefore suggest that the definition (from the same page) :

    generic-message  = start-line
                                     *message-header
                                     CRLF
                                     [message-body]

    start-line               = Request-Line |
                                    Status-Line

    message-header  = *(general-header
                                     | request-header
                                     | response-header
                                     | entity-header)

is incorrect as this would allow zero or more message header contents
twice, once
for each * (i.e. will still equal 0 or more message headers). I suggest
that this 
definition should  in fact read (using the definition and example in
Section 3.6 of ,
"Augmented BNF for Syntax Specification", Nov 97, Crocker and Overell, 
RFC 2234) as follows :

    generic-message  = start-line
                                     1*message-header
                                     CRLF
                                     [message-body]

    start-line               = Request-Line |
                                     Status-Line

    message-header  = general-header
                                     | request-header
                                     | response-header
                                     | entity-header

Page 31 
======
Section 6.6. the Header Field Format text description here is also
inconsistent with 
the BNF. 

     'Header fields can be extended over multiple lines by preceding
each 
     extra line with a space or tab.'

The BNF does not appear to enforce this rule.  

    message-header              = field-name ":" [field-value] CRLF
    field-name                      = token
    field-value                      = *(field-content | LWS)

I suggest that maybe something like the following would be more
suitable:

    message-header              = field-name ":" [field-value] CRLF
[further-field-values]
    field-name                      = token
    field-value                      = *(field-content | LWS | CRLF
[further-field-values] )
    further-field-values        = 1LWS field-value

General Point
==========
It was straight forward to pick up the inconsistency between the
semantics of 
the text and the syntax of the definitions in these cases. However, it
might be that 
other similar inconsistencies exist where the text description of a rule
*only* refers to 
that rule (several examples throughout the text). If the text
descriptions do not 
describe the expected content this makes detection of such
inconsistencies difficult 
at this early stage.

Hoping you find this information useful.

Kind regards,

Jeremy Buller

------------------------------------------------------------------------
-------------------------------------
Jeremy Buller 
IT&N
Roke Manor Research Ltd, Old Salisbury Lane, Romsey, Hampshire. SO51
0ZN. UK .           
E-mail: [email-masked] 
Tel: +44 (0)1794 833666 
Fax: +44 (0)1794 833434
 
------------------------------------------------------------------------
-------------------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 31 Jul 1998 16:50:11 -0400

>     message-header  = general-header

Fixed.

>     field-value                      = *(field-content | LWS)

This is straight from HTTP/1.1. Extension over multiple line is
accomplished via LWS. However, the definition of LWS in the 'Common
Tokens' section was inconsistent with HTTP and has now been brought in
line:

LWS = [CRLF] 1*( SP | HT )

> General Point

It would be nice if there was an automated ABNF checker...

> Hoping you find this information useful.

Thanks for your careful reading; let us know if you find anything else.