Subject: Re: syntaxes-09 notes

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 6 Mar 2005 19:56:56 +0100

Kurt D. Zeilenga writes:
>At 10:28 PM 2/6/2005, Steven Legg wrote:
>>Hallvard B Furuseth wrote:
>>>>3.3.11.  Facsimile Telephone Number
>>> (..)
>>>It would be nice if a description (maybe ABNF) of this syntax is added,
>>>similar to the ABNF of GeneralizedTime.  (Or maybe put it under
>>>telephoneNumber and refer to that.)
> (...)
> Second, I don't think it appropriate to provide an ABNF here.

OK...

> The E.123 format is best considered a free format.  While it
> can certainly be argued that a more precise format would be
> better, it is not generally within our scope to update X.500
> syntaxes (or to introduce new syntaxes).

That's fine by me.

However, you rejected a complaint that OpenLDAP did not accept
"---" as a phone number.  Have you changed your mind, or do I
misunderstand what you mean by free format?

Here:

http://www.openldap.org/lists/openldap-software/200409/msg00099.html

>From: "Kurt D. Zeilenga" <[email-masked]>
>Date: Mon, 06 Sep 2004 00:45:54 -0700
>
>At 04:24 PM 9/5/2004, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>>At 02:26 PM 9/5/2004, vadim wrote:
>>>> 1) 2.2.15 does not accept value "---" of attribute
>>>> telephoneNumber, (...)
>>>
>>> "---" is not a telephone number.  It is proper for a LDAP server
>>> to disallow the addition of such garbage.
>>
>> Not as far as I can tell.  At least, it's valid according to the
>> telephone number syntax in draft-ietf-ldapbis-syntaxes-08.txt.
>
> Maybe the I-D is not as clear as it could be.
>
> Values of this syntax represent telephone numbers using the E.123
> format encoded in a printable string.  The printable string "---"
> simply doesn't represent a telephone number.  (Maybe it represents
> "no telephone number", but that's not a telephone number.)

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 07 Mar 2005 22:55:51 -0600

>misunderstand what you mean by free format?

E.123 a free format for representing a telephone number.  I
argue that it is not a telephone number and, much like dates
like 31 February 2006, can be rejected by the implementation.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 8 Mar 2005 11:26:28 +0100

> like 31 February 2006, can be rejected by the implementation.

Then [Syntaxes] should at least allow invalid telephone numbers to be
rejected.  An in standards context, I'm not sure what "not a valid
telephone number" could mean other than "does not follow E.123".

I would note that we've been stuffing phone numbers from text fields in
other databases into LDAP's telephoneNumber, and while these textual
phone numbers may contain enough info or context to make them clear to a
human, it may not be possible for a computer program to decide what they
mean.  E.g. "52813/52828" = +47-228 52813 and +47-228 52828 (+427-228*
belongs to our organization).  Or deciding whether something is a phone
number + trailing line number, or an international number where someone
has omitted a '00 or '+' country prefix, or two 5-digit phone numbers.
The data sources have been cleaned up considerably now, but some years
ago too restrictive phone number syntax would have meant we had to omit
a lot of numbers from the directory.  Whether such a situation is
LDAPbis' problem or the organization's problem is another matter, of
course.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 08 Mar 2005 07:08:29 -0600

>telephone number" could mean other than "does not follow E.123".

"telephone number" is an abstraction.  E.123 provides a format
for representing values of that abstraction.  Aside from the
input violates the format, input can violate the abstraction.
This, IMO, is a general principle.  Servers are not required
to understand details of the abstraction, but if they are, they
certainly can reject values which are not consistent with
that abstraction.

>mean.

I also note that the telephoneNumber abstract is actually an
"international telephone number".  "52813/52828" can be consider
invalid because it represents multiple numbers.  "52813/52828"
can be considered invalid because these do not represent
international telephone numbers.

>E.g. "52813/52828" = +47-228 52813 and +47-228 52828 (+427-228*
>belongs to our organization).

>Or deciding whether something is a phone

The program can reject values that don't start with "+" country
prefix (ignoring other characters that can be ignored).  The
abstraction is, after all, an international telephone number.

>a lot of numbers from the directory.

Or, to look it another way, the less restrictive syntax allows
a lot of garbage into the directories.

>Whether such a situation is