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

RE: Models: preservation of user information

Title: Models: preservation of user information
Yes, the application may wish that case be preserved but, for the directory, the issue is that case is not important for those attributes - and the matching rule bears that out. The matching rule isn't only used for retrieving attributes, it is also used when adding and modifying values. The matching rule is tied up with what it means to be a distinct, recognisable value. In any event, you should realise that you cannot add in a 'MUST' after the event.
-----Original Message-----
From: Christopher Oliva [mailto:Chris.Oliva@entrust.com]
Sent: Friday, 31 January 2003 11:41
To: Ramsay, Ron; ietf-ldapbis@OpenLDAP.org
Subject: RE: Models: preservation of user information

It means it's not important for matching values. When I retrieve values from the directory, I expect to get the same values I entered since I am not asking the directory to evaluate an equality assertion. Although upper and lower case may be equivalent, the meaning is not always the same to applications or users.
 
Many standard attributes are already defined with caseIgnoreMatch and can't be changed to caseExactMatch without breaking existing clients that expect to search using the caseIgnoreMatch matching rule.
 
Chris.
-----Original Message-----
From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com]
Sent: Thursday, January 30, 2003 6:19 PM
To: Christopher Oliva; ietf-ldapbis@OpenLDAP.org
Subject: RE: Models: preservation of user information

You should store the information in an attribute whose matching rule is caseExactMatch. The meaning of using caseIgnoreMatch is that case is not important.
-----Original Message-----
From: Christopher Oliva [mailto:Chris.Oliva@entrust.com]
Sent: Friday, 31 January 2003 06:30
To: ietf-ldapbis@OpenLDAP.org
Subject: Models: preservation of user information


Section 6.1 includes this paragraph:

  Where such requirements have not be explicitly stated, servers SHOULD
  preserve the value of user information but MAY return the value in a
  different form.  And where a server is unable (or unwilling) to
  preserve the value of user information, the server SHALL ensure that
  an equivalent value (per Section 2.3) is returned.

This would allow the server to return values that are not identical to the original values added by an application. Partly because sometimes, equality rules only determine equivalency instead of exact equality.

I think this could lead to problems. For instance, name information for attributes with a caseIgnoreMatch equality matching rule might be returned in the wrong case which would actually be a loss of information for the application.

I would prefer mandating servers to return the exact value that was originally added (when there are no explicit constraints in the schema definition for that item). Essentially this would be changing the above paragraph to:

  Where such requirements have not been explicitly stated, servers MUST
  preserve the value of user information (return the same values that
  were originally added).

Chris.