Updates for draft-hinckley-ldapv3-attr-syntax-00 (LONG)

["Ryan Moats" <rmoats@coreon.net>]

Mark-

Some thoughts from my plane trip... If you'd like I can put these in
the I-D...

Ryan

1. Having looked through this draft, I can offer the following ABNF
description for updating the current 822 based BNF. Note, this text is
written assuming that RFC 2234 replaces RFC 822 in [13] as this is
the only reference to that RFC in 2252.  As you can see, most of the
BNF comes through unchanged, I only shortened the initial descriptions

====
4.1 Common Encoding Aspects

  For the purposes of defining the encoding rules for attribute
  syntaxes, the following BNF definitions will be used.  They are based
  on the BNF styles of RFC 2234 [13].

   a = %x41-5A / %x61-7A
   d = %x30-39 
   hex-digit =  d / "a" / "b" / "c" / "d" / "e" / "f"
   k = a / d / "-" / ";"
   p = a / d / """ / "(" / ")" / "+" / "," / "-" / "." /
       "/" / ":" / "?" / " "
   letterstring    = 1*a
   numericstring   = 1*d
   anhstring       = 1*k
   keystring       = a [ anhstring ]
   printablestring = 1*p
   space           = 1*" "
   whsp            = [ space ]
   utf8            = <any sequence of octets formed from the UTF-8 [9]
                      transformation of a character from ISO10646 [10]>
   dstring         = 1*utf8
   qdstring        = whsp "'" dstring "'" whsp
   qdstringlist    = [ qdstring *( qdstring ) ]
   qdstrings       = qdstring / ( whsp "(" qdstringlist ")" whsp )


  In the following BNF for the string representation of OBJECT
  IDENTIFIERs, descr is the syntactic representation of an object
  descriptor, which consists of letters and digits, starting with a
  letter. 

  When encoding 'oid' elements in a value, the descr encoding option
  SHOULD be used in preference to the numericoid [add reference to updated
  2251]. An object descriptor is a more readable alias for a number
  OBJECT IDENTIFIER, and these(where assigned and known by the
  implementation) SHOULD be used in preference to numeric oidsto the 
  greatest extent possible.  Examples of object descriptors in LDAP are 
  attribute type, object class and matching rule names.

    oid             = descr / numericoid

    descr           = keystring

    numericoid      = numericstring *( "." numericstring )

    woid            = whsp oid whsp

    ; set of oids of either form
    oidlist         = woid *( "$" woid )

    oids            = woid / ( "(" oidlist ")" )

    ; object descriptors used as schema element names
    qdescrs         = qdescr / ( whsp "(" qdescrlist ")" whsp )

    qdescr          = whsp "'" descr "'" whsp

    qdescrlist      = [ qdescr *( qdescr ) ]

====

2. In addition, here are some suggested additions to cover the 
comments throughout the document.  They look right to me, but
I'll bow to somebody else's experience if they should be something
else.  I'm not sure if SASL Mechanism names are case sensitive or
not and I'm still not entirely clear on what case means with UTF8
strings, but I have some more reading to do on that.

I didn't have text in front of me for the IA5 Ordering Match Rules
so I didn't add them, and I took a complete stab at the octet substring
assertion.  If somebody knows the OID, great, I don't off the top
of my head.

====

   ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation
    EQUALITY distinguishedNameMatch )

   ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation
    EQUALITY caseIgnoreIA5Match )

   ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation
    EQUALITY objectIdentifierMatch )

   ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation
    EQUALITY objectIdentifierMatch )

   ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation
    EQUALITY caseIgnoreMatch )

   ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation
    EQUALITY integerMatch )

   ( 2.5.13.5 NAME 'caseExactMatch'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   ( 2.5.13.18 NAME 'octetStringOrderingMatch'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

   ( 2.5.13.6 NAME 'caseExactOrderingMatch'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   ( 2.5.13.19 NAME 'octetStringSubstringsMatch'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

   ( <TBD> DESC 'Octet Substring Assertion' )

     The Octet Substring Assertion is encoded according to the
     following ABNF:

     octetsubstring = [initial] any [final]
     initial = octetvalue
     any = "*" *(octetvalue "*")
     final = octetvalue

     where <octetvalue> is an octet string as described in [1].

====

3. Lastly, there are ten matching rules from the copy of X.520 I was
reading on the plane that aren't in either the 2252 update or 
the 2256 update... I'm wondering if they should be included.
I've run into situations where several of them would have been
useful already...

caseExactSubstringMatch
numericStringOrderingMatch
caseIgnoreListSubstringMatch
booleanMatch
integerOrderingMatch
uTCTimeMatch
uTCTimeOrderingMatch
directoryStringFirstComponentMatch
wordMatch
keywordMatch

What does the working group want to do with these?

Ryan Moats