[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: I-D ACTION:draft-ietf-ldapbis-models-07.txt



At the very least, I suspect someone will want DIGIT and DOT in order to
use numeric oids. I'm not aware of any current implementations that the
restriction will break, so I'm not willing to burn a bunch of time
arguing about allowing more.

Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 4/3/03 12:59:21 AM >>>
At 02:20 PM 4/2/2003, Jim Sermersheim wrote:
>extensions (found in schema element syntaxes like
>ObjectClassDescription) no longer allows a word like "x-1.2.3.4"
>This was not a limitation in the original spec, is there a reason for
>allowing only ALPHA HYPHEN, and USCORE?

RFC 2252 did not define a production for terms.  I came
up with xstring by first examining what would be appropriate
for all terms (both private and non-private).  I came up
with:
        term = ALPHA *( ALPHA / HYPHEN / USCORE )

(I don't recall the exact rationale... likely I just thought
keystring then realized USCORE was used in some terms).  I
then derived xstring from this.

I think xstring should be quite restrictive.  But as it unlikely
that adding a few additional characters would break any
implementations, I'm fine with adding one or two additional
characters which folks are currently using or believe would be
useful.

>I think it should allow %x21-7E (after the x-)

I think that would be problematic.

Is xstring known to be too restrictive (e.g., you known of
an existing private term which it disallows)?  Or you just
would like to have some more options?

If yes to either, I prefer to add to only add a few.  Would
adding DOT be sufficient?