[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Updates for draft-hinckley-ldapv3-attr-syntax-00 (LONG)
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