Re: Grammar nits (Re: [Fwd: I-D ACTION:draft-good-ldap-ldif-04.txt])

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Harald Tveit Alvestrand writes:
> I do wish you would switch to RFC 2234 ABNF rather than RFC 822 ABNF.
> RFC 2234 is a *little* better specified - and I've got a parser for it.

How do we say "any character except NUL, CR or LF" in ABNF when we don't
know the max integer code of a character in the parser's characer set?
Assume iso10646 and say something like `%x01-09/%x0B-0C/%x0E-7FFFFFFF'?

> About 5) Changed "0,1*xxx" "0*1xxx" in compliance with RFC822
> 
> You missed one - in change-moddn.

No.  But he missed "to" in the sentence above, maybe you misunderstood.
           Change "0,1*xxx" to "0*1xxx" in...

> Personally, I also find the number of <prose-val> in the grammar
> disturbing, especially since many of them can easily be replaced by
> character ranges.

Like this?  (Please fill in `???' in `safe' and `safe-initval'.)

  dn                   = 0*1(rest-line) ; put the <prose-val> text here
  base64-dn            = rest-line      ; ...
  rdn                  = rest-line      ; ...
  base64-rdn           = rest-line      ; ...
  url                  = rest-line      ; ...
  value                = rest-line      ; (See Note 9, below)
  base64-value         = rest-line      ; ...

  ldap-oid             = ldif-word      ; ...
  attribute-description= ldif-word      ; ...

  rest-line            = safe-initval *safe
  ldif-word            = 1*ldif-wordchar

  safe                 = ???
                         ; any character except NUL, CR or LF

  safe-initval         = ???
                         ; any <safe> character except SPACE, ":" or "<"

  ldif-wordchar        = %x41-%x5a / %x61-%x7a / DIGIT / "-" / "." / ";"
                         ; ASCII letters, digits, "-", ".", and ";"

  SPACE                = %x20     ; ASCII SP, space
  CR                   = %x0D     ; ASCII CR, carriage return
  LF                   = %x0A     ; ASCII LF, line feed
  NUL                  = %x00     ; ASCII NUL
  DIGIT                = %x30-39  ; Any ASCII decimal digit


Gordon Good writes:
> I've submitted a new version of the LDIF draft.

...with some new bugs:-(

This change to `change-modrdn' is both upwards or downwards incompatible
with the old grammar:

>                          0*1("newsuperior:"     FILL (dn /
>                                             ":" FILL base-64-dn) SEP)

It  rejects "newsuperior:: Y249Zm9v"   (accepted by old grammar)
but accepts "newsuperior: : Y249Zm9v"  (rejected by old grammar)
Fix:
                          0*1("newsuperior:" (    FILL dn /
                                              ":" FILL base-64-dn) SEP)
Or maybe the grammar should not have split "::" anywhere, but used
                          0*1("newsuperior" (":"  FILL dn /
                                             "::" FILL base-64-dn) SEP)
and similar constructs elsewhere.


Next,

>   control              = "control: FILL ldap-oid            ; controlType

needs an endquote after `"control:'.


Next:  The SEP at the end of in `value-spec' is bogus, because
`value-spec' is used _conditionally_ here in `control':

>                          0*1(value-spec)                    ; controlValue
>                          SEP

Fix:  Remove SEP in `value-spec' and put it back at the end of
`attrval-spec'.


Next,

>   FILL                 = 1*SPACE

the old grammar corresponds to `FILL = *SPACE'.  I don't see why you
changed it to 1*SPACE, but the change is incomplete.

Simplest fix:

* Restore `FILL = *SPACE'.

* Replace `FILL' with `1*SPACE' in this line:
                          0*1 (FILL ("true" / "false"))      ; criticality
  which is the only place I know where SPACE is not optional.

Or if you wish to keep FILL = 1*SPACE, you must at least:

* fix the examples to use spaces where required,
  e.g. "sn:Jensen" -> "sn: Jensen".

* allow FILL to be absent in front of empty and omitted optional values:

  - dn-spec              = "dn:" (FILL dn / ":" FILL base64-dn)
      If a DN can be empty, that should be "dn:" 0*1(FILL dn / ...)

  - similarly, the if the DN after 'newsuperior:' can be empty:
                         0*1("newsuperior:"    (    FILL dn /
                                                ":" FILL base-64-dn) SEP)
      should be
                         0*1("newsuperior:" 0*1(    FILL dn /
                                                ":" FILL base-64-dn) SEP)
      (assuming the "newsuperiour: fix above has been applied)

  - value-spec           = ":" (     FILL 0*1(value)  / ... ) SEP
      should be                ( 0*1(FILL 0*1(value)) / ... ) SEP

  - You might also allow ":" and "<" in `safe-initval' and modify Note 4
    accordingly.  Since a value is always preceded by SPACE, there is
    no ambiguity if it starts with ":" or "<".

Come to think of it, Note 4 doesn't need to require values that start
with `:' or `<' to be base-64 encoded even if FILL=*SPACE.  It could
instead require them to be either preceded by SPACE or base-64 encoded.


BTW,

>    Differences between draft-good-ldap-ldif-03.txt and
>    draft-good-ldap-ldif-04.txt
> 
>    1) The grammar now requires that an LDIF file end with one or more 
>    SEP sequences (newlines). This was inadvertantly prohibited in 
>    earlier revisions of the grammar. 

No, that was a misunderstanding.

-- 
Hallvard