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

Re: matching for facsimileTelephoneNumber

Hi All!

The bottom line is that the definition of the facsimileTelephoneNumber
attribute can not be changed.  IMHO, specification of a
facsimileTelephoneNumber matching rule and including it in the attribute
specification would change the attribute.  Therefore, there should be no
impact on LDAPv3BIS.  Also, IMHO, a facsimileTelephoneNumber matching
rule, which would not be formally cited by the attribute definition,
would be difficult to implement because the syntax is complex (SEQ). 
So, I do not support this as a new task for LDAPEXT.

Kathy Dally


Ryan Moats wrote:
> 
> ?!?!  I agree with what you said, but the request was to
> specify a matching rule for facsimileTelephoneNumber.
> This is not currently done by X.520 so I claim the
> matching rule is NOT part of the "core" spec and so is
> out of scope.  If we are going to start specifying
> matching rules for things in X.520 that don't have them
> I claim we've strayed into new functionality.
> 
> I think we are in agreement about the approriateness
> of this suggestion, but for different reasons.
> 
> Ryan
> 
> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
> Sent: Thursday, December 21, 2000 1:41 PM
> To: Ryan Moats
> Cc: Stig Venaas; ietf-ldapbis@OpenLDAP.org
> Subject: RE: matching for facsimileTelephoneNumber
> 
> At 09:05 AM 12/21/00 -0600, Ryan Moats wrote:
> >IMHO... If it isn't in X.520, then its a topic for LDAPEXT.
> >(ietf-ldapext@netscape.com). No new functionality in LDAPBIS.
> 
> I note, per our charter, that all schema items which are not
> required and/or described by the LDAPv3 "core" technical
> specification are not within scope of the LDAPbis WG.
> 
> facsimileTelephoneNumber is described by the LDAPv3 "core"
> technical specification, so it is within scope.  However,
> the proposed change, IMO, would be inappropriate as it
> would create, not resolve, interoperability problems.
> 
> Kurt