Thanks! I think this confirms my suspicion that a phone number should be modeled as a String (with a validated format).
On Tue, Feb 17, 2026 at 11:59 AM Emmanuel Lecharny <[email protected]> wrote: > Hi Brian, > > you are using antlr V4 which has no issue with Java 21. > > > Regarding the TelephoneNumber filter, we have already such a piece of code > in Apache LDAP API. It's based on a regexp: > > private static final String DEFAULT_REGEXP = "^ *[+]? *((\\([0-9- > ,;/#*]+\\))|[0-9- ,;/#*]+)+$"; > > ... > > // We will use a regexp to check the TelephoneNumber. > > boolean result; > > // Not sure this is 100% necessary... > > synchronized ( defaultPattern ) > > { > > result = defaultPattern.matcher( strValue ).matches(); > > } > > if ( LOG.isDebugEnabled() ) > > { > > if ( result ) > > { > > LOG.debug( I18n.msg( I18n.MSG_13701_SYNTAX_VALID, value ) ); > > } > > else > > { > > LOG.debug( I18n.err( I18n.ERR_13210_SYNTAX_INVALID, value ) ); > > } > > } > > return result; > > I'm pretty sure it's similar (except the 'tel:' at the beginning). I'll > check. > > So regarding your questions: > > 1. In LDAP API , are phone numbers modeled into individual parts? or treated > as just a string? > > they are treated as a String. > > 2. If not has this been something anyone has ever ask for? > > > Basically, there is a ITU recommendation for the telephone number syntax: > > /** > > * A SyntaxChecker which verifies that a value is a TelephoneNumber > according to ITU > > * recommendation E.123 (which is quite vague ...). > > * <p> > > * A valid Telephone number respects more or less this syntax : > > * > > * <pre> > > * " *[+]? *((\([0-9- ,;/#*]+\))|[0-9- ,;/#*]+)+" > > * </pre> > > * > > * If needed, and to allow more syntaxes, a list of regexps has been added > > * which can be initialized to other values > > * > > * @author <a href="mailto:[email protected]";>Apache Directory > Project</a> > > */ > > As said in the header, it's 'vague', so we have added a way for those who > would like to use another > > regexp to inject it into the syntax checker... > > Hope it helps. > > > On 2/17/26 17:45, Brian Demers wrote: > > Awesome! > > SCIMple has a couple of ANTLR parsers: > 1. Filters (e.g. a query) > 2. Phone numbers. > https://github.com/apache/directory-scimple/tree/develop/scim-spec/scim-spec-schema/src/main/antlr4/org/apache/directory/scim/spec > > IMHO, the phone number object is more complex than necessary. IMHO, this > _could_ just be a string with some basic validation > (IdPs will likely have additional requirements/validation as well) > > From the SCIM spec: > > Service providers SHOULD canonicalize the value according to [RFC3966] > > format, when appropriate. > > This may be an area that _might_ benefit for some consistency between > Directory projects. > > After a quick search it looks like LDAP API, is just doing some basic > validation:https://github.com/apache/directory-ldap-api/blob/69965740b68e10367816697ac3548beb528e255d/ldap/model/src/main/java/org/apache/directory/api/ldap/model/schema/syntaxCheckers/FacsimileTelephoneNumberSyntaxChecker.java#L57 > > Questions: > 1. In LDAP API , are phone numbers modeled into individual parts? or > treated as just a string? > 2. If not has this been something anyone has ever ask for? > > IMHO, it's a cool feature, but I'm not sure if it is worth the > burden/complexity in SCIMple. (This is logic that could be moved into an > implementing project). > > Thoughts? > > On Sun, Feb 15, 2026 at 2:33 AM Emmanuel Lecharny <[email protected]> > <[email protected]> > wrote: > > > Hi! > > 4 months ago, I started to replace all the LDAP API antlr generated > parses (there were 7 of them). > > Today, I just committed the replacement of the ACIItem parser. It speeds > up the parsing of an ACI by a x3 factor, removed all the synchronized > sections, fixed some wrong tests, and removed 13 classes. > > This move was necessary as the antlr parser we were using (2.7.7) wasn't > usable with Java 21+. > > > The last parser to be removed is the DN parser. A big piece of work. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
