Subject: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 11 Jun 2003 02:22:52 -0700 (PDT)

This message initiates a LDAPbis Working Group Last Call on the two
documents:

                LDAP: Syntaxes and Matching Rules
                draft-ietf-ldapbis-syntaxes-06.txt
                          3 June 2003

and

            LDAP: Internationalized String Preparation
                draft-ietf-ldapbis-strprep-00.txt
                          26 May 2003

The purpose of this WG Last Call it to ensure that the Working Group has
achieved consensus that these documents are suitable for publication as
IETF Standards Track RFCs.

Please review the documents for both technical and editorial problems.
Technical issues should be discussed on this list.  Editorial issues may
be sent to the document editors.

The Last Call period will end on Wednesday, June 25, 2003.

Upon completion of the Last Call, the WG chair(s) will take action based
upon the consensus of the WG.  Possible actions include:

  1) recommending to the IETF Application Area Directors that the
     documents, after possible editorial or other minor changes, be
     considered by the IESG for publication as Standards Track RFCs
     (which generally involves an IETF-wide Last Call); or

  2) requiring that outstanding issues be adequately addressed prior
     to further action (including, possibly, another Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process.  So, please read and comment!

 - RL "Bob" Morgan
   LDAPbis co-chair

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 18 Jun 2003 12:40:50 +1000

Some minor edits to draft-ietf-ldapbis-06.txt required:

1) The title of RFC 3383 is incorrect in the references,

2) Section 5.2.16 omits the sentence (thanks to Hallvard for picking it up),

   "The LDAP definition for the numericStringSubstringsMatch matching
   rule is:"

3) The telephoneNumberMatch and telephoneNumberSubstringsMatch need to
   be added to the list in the first sentence of section 5.2. The comment
   on telephoneNumberMatch in Appendix B, case 25 needs to be struck out.

Regards,
Steven

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of RL 'Bob' Morgan
> Sent: Wednesday, 11 June 2003 19:23
> To: IETF ldapbis WG
> Subject: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
>
>
>

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 18 Jun 2003 13:20:28 +1000

> Some minor edits to draft-ietf-ldapbis-06.txt required:

That should be draft-ietf-ldapbis-syntaxes-06.txt (doh!).

Also, one more correction:

4) [ROADMAP] isn't provided in the references. It is

   [ROADMAP] Zeilenga, K., "LDAP: Technical Specification Road Map",
   draft-ietf-ldapbis-roadmap-xx.txt, a work in progress, March 2003.

Regards,
Steven

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 23 Jun 2003 09:26:24 -0700 (PDT)

A reminder that the Last Call period on these drafts ends this Wednesday,
June 25.

 - RL "Bob"

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 24 Jun 2003 21:28:54 +0200

> A reminder that the Last Call period on these drafts ends this Wednesday,

Whoops.  Thanks for the reminder.  I've been sitting on this for too
long:

I have some problems with ldapbis-strprep.  I posted some of them before
to the strmatch draft, but I don't think I got a reply.

> 2. String Preparation
>  The following six-step process SHALL be applied to each presented and
>  attribute value in preparation for string match rule evaluation.

Not to octet strings.  Do they count as _string_ match?

> 2.2. Map
>
>  All other control code points (e.g., Cc) or code points with a control
>  function (e.g., Cf) are mapped to nothing.
>
>  ZERO WIDTH SPACE (U+200B) is mapped to nothing.  All other code points
>  with Separator (space, line, or paragraph) property (e.g, Zs, Zl, or
>  Zp) are mapped to SPACE (U+0020).

Can you list these (mostly as character ranges, I hope), or are there
too many of them?

For syntaxes/matching rules that expect non-empty strings, character
removal in step 2.2 can change a valid (non-empty) string to an invalid
(empty) one.  If that happens, I suggest a SPACE should be inserted for
matching rules where space can be insignificant.  I don't know what to
do about matching rules where space is always significant.

For the same reason,

> 2.6.1. Insignificant Space Removal
>  A string consisting entirely of spaces is equivalent to a string
                                          ^^^^^^^^^^^^^^^^
>  containing exactly one space.

This doesn't say anything about how to translate the string.
I think it should be "... is _translated to_ a string containing...".

2.6.2 (numericString) and 2.6.3 (telephoneNumber) should also re-insert
a single space if they would translate a non-empty string to an empty
one, since these syntaxes also expect a non-empty string.
That is, I assume 'PrintableString (SIZE(1..ub-telephone-number))' in
the definition of the Telephone Number syntax means one or more
character.

Finally, there is no section 2.6.  Sections 2.6.* should be 2.5.*.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 24 Jun 2003 16:55:06 -0700

>Not to octet strings.  Do they count as _string_ match?

The algorithm is intended to apply (as specified in other documents)
to character string matching.   I suggest inserting the word 'character'
before 'string' in the above sentence and likewise in a few other places.

>Can you list these (mostly as character ranges, I hope), or are there

I could.  But I prefer to say it once than twice to avoid possible
inconsistencies.  I am not adverse to adding an informative mapping
table as an appendix.  Would that adequately address your concern?

>(empty) one.

If either the presented or stored values are mapped to empty
strings, then the match is Undefined.  I don't see that as being
much of a problem, especially since caseIgnoreIA5Match("",X)
can be argued should behave just like caseIgnoreMatch("",X)...
evaluated to Undefined.

>If that happens, I suggest a SPACE should be inserted for
>matching rules where space can be insignificant.

I think this would be bad as caseIgnoreMatch(""," ") would
evaluate to TRUE not Undefined.

>>  A string consisting entirely of spaces is equivalent to a string

I suggest combining the statement with the previous paragraph:
   A string consisting entirely of spaces is to be replaced with
   a string of exactly one space.  Otherwise, the following spaces               

>the definition of the Telephone Number syntax means one or more

Okay.

>Finally, there is no section 2.6.  Sections 2.6.* should be 2.5.*.

Yes.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 25 Jun 2003 10:34:20 +0200

> table as an appendix.  Would that adequately address your concern?

That's fine.

> strings, then the match is Undefined.

Well, that's exactly my problem.  I think invalid strings should not be
inserted in the directory, and valid strings should compare as true or
false.  I don't like valid strings that do not compare as true or false.

I would't have a problem if non-empty strings that are mapped to "" were
invalid so they couldn't even be inserted in the directory.  But that
looks like another big can of worms, I don't think we want to go there.

> I don't see that as being much of a problem, especially since
> caseIgnoreIA5Match("",X) can be argued should behave just like
> caseIgnoreMatch("",X)...  evaluated to Undefined.

But it isn't "" which is compared to X.  It's "<SOFT HYPHEN>" or
something.

> evaluate to TRUE not Undefined.

No, I did not mean "" to map to " ".  Only insert a space if a non-empty
string would map to an empty one.

>    A string consisting entirely of spaces is to be replaced with a
>    string of exactly one space.  Otherwise, the following spaces are
>    regarded are to be removed:

Fine.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 25 Jun 2003 10:40:16 +0200

>>    regarded are to be removed:

On second thought, I think "are regarded" should go away.
"are regarded are" looks strange.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 25 Jun 2003 13:06:53 +0200

> looks like another big can of worms, I don't think we want to go there.

Perhaps I should add a little here.

[Models] 2.3 (Structure of an Entry) says:
  No two values of an attribute may be equivalent.
  Two values are considered equivalent if they would match according to
  the equality matching rule of the attribute type.

So what happens if I attempt to give an attribute in an entry two valid
values that map to "" and thus match as undefined?  Are the values
equivalent, or not?

- If they are not equivalent, then we can put several "<SOFT HYPHEN>"
  values in one attribute in an entry.

- If they are equivalent, then we can only add the value "<SOFT HYPHEN>"
  if the attribute has no other values.  After that, an attempt to add
  _any_ value will fail.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 25 Jun 2003 13:26:28 +0200

> values that map to "" and thus match as undefined?  Are the values

Sorry, I mean two valid values where at least one maps to "", so they
match as undefined.

Hopefully this will be the last followup-to-self for a while...

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 25 Jun 2003 07:38:01 -0700

>values that map to "" and thus match as undefined?  Are the values

I'd argue, for attributes which have an EQUALITY RULE, that only
values which EQUALITY(value,value) is True can be added to the
directory.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 25 Jun 2003 21:44:10 +0200

> values which EQUALITY(value,value) is True can be added to the

This diverges from X.500, doesn't it?
Also, not that I mind, but it sounds a little like LDAPv4 to me...

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 25 Jun 2003 13:39:12 -0700

>Also, not that I mind, but it sounds a little like LDAPv4 to me...

Well, it might be a bit divergent.  I'd have to carefully
review X.501 to see what it says here.

>  values in one attribute in an entry.

Obviously that would be counter to X.501.

>  if the attribute has no other values.  After that, an attempt to add

This, I believe, is consistent with X.501.  That's how the matching
rules behave.

When I first read your suggestion, I assumed you wanted to replace
"" with " ".  I think I am fine with your suggestion that if the
input to the mapping step is non-empty and the mapping would result
in an empty string, the output is instead " ".

This handles the map to "" issues, but it does nothing to allow
both "foo<REPLACEMENT CHARACTER>bar" and "barfoo" to co-exist as
values of CN.  Personally, I don't think "foo<REPLACEMENT CHARACTER>bar"
should be an allowed value of CN.

Anyways, to implement this suggestion, I think I rather say that the
output of the translation step must be non-empty (if empty,
the preparation fails, match is Undefined).  Remove the prohibition
of empty strings in the prohibit section and insert the space during
the insignificant space removal step.   My rationale for doing it
this way is that mapping and prohibition should be done on a
character-by-character basis and string-wise things should be
done either in first or last steps.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 25 Jun 2003 23:18:49 +0200

Kurt D. Zeilenga writes:
> This, I believe, is consistent with X.501.

Well, if you say so.  Both the alternatives I listed sound weird to me.
But perhaps this is the best we can do.

> That's how the matching rules behave.

Well, it's how LDAP (and X.500?) {will} _use_ the matching rules.
If I understand you correctly, the part of [Models] 2.3 which I quoted
should be changed to something like

  If the attribute type has an equality matching rule, any two values of
  the attribute must compare as false according to that matching rule.

> values of CN.

Nor does it let "foo<REPLACEMENT CHARACTER>bar" to co-exist with _any_
value, since since they would match as Undefined whatever the other
value is.

> Personally, I don't think "foo<REPLACEMENT CHARACTER>bar"

No opinion.  I don't even know what <REPLACEMENT CHARACTER> is.

> of empty strings

You mean, move the prohibition of empty strings from the Prohibit
step to the Transcode step?

> in the prohibit section and insert the space during
> the insignificant space removal step.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 25 Jun 2003 15:13:10 -0700

Yes.

Yes.

>No opinion.  I don't even know what <REPLACEMENT CHARACTER> is.

You might want to consider all the other cases where the preparation
fails and hence the rule evaluation is Undefined.  There are many.

Yes.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 26 Jun 2003 08:10:54 +0200

> fails and hence the rule evaluation is Undefined.  There are many.

True.  Well, I wouldn't want Private Use code points to be prohibited
from existing in the directory, at least.  They exist to be used, and
someone who uses them will want to put them in LDAP.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 26 Jun 2003 08:54:04 +0200

>> If I understand you correctly, the part of [Models] 2.3 which I
>> quoted should be changed to something like
>>
>>  If the attribute type has an equality matching rule, any two values
>>  of the attribute must compare as false according to that matching
>>  rule.
>
> Yes.

In view of this, I'm beginning to dislike that Prohibit step.
If I have a purely local LDAP directory, why shouldn't I be allowed to
give an attribute two values where one uses a Private Use code point?
Or to search for - and find - the one with a Private Use code point by
searching for that exact string, at least?
The results of choosing to do this would of course be my responsibility.

I think it would be better if servers SHOULD implement the Prohibit step
but MAY allow it to be turned off, and recommend that managers keep it
turned on for globally accessible directories.

Then make the problem with certificate chain validation a problem for
certificates, not for string matching in general:  Either prohibit the
characters listed in the Prohibit step from existing in certificates, or
say that the Prohibit step MUST be performed when checking components of
certificates.  In either case, these characters won't match anything.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 27 Jun 2003 09:52:12 -0700

>give an attribute two values where one uses a Private Use code point?

These rules are designed for interoperability between independently
developed implementations which you are likely to have even in
local environments.  If all directory agents do not agree on matching
rule semantics, interoperability problems will occur.  Some of these
will have impact upon security.  These matching rules are not just used
by DSAs to locate information, but used in DUAs to correlate information
provided by the DSAs.  To be appropriate for naming of objects and
values of security related attributes, I think the appearance of a
Private Use code points in strings to be matched with these rules
need to cause the evaluation to be Undefined.

Note that one is always free to define other schema elements to meet
local needs.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 27 Jun 2003 21:16:38 +0200

Kurt D. Zeilenga writes:
> local environments.  (...)

We have at least two LDAP servers here (OpenLDAP and AD), but will never
need any interoperability between them.

Interoperability is important, but I think the price is too high
sometimes.  Like in this case.  I don't like to have to pay too much for
features I know I won't need.  That's why I think the prohibit step
should only be a SHOULD or RECOMMENDED, with a 'MAY allow admins to turn
it off'.

> Note that one is always free to define other schema elements to meet

That only helps if I can hack the server to add new matching rules, or
if I'm satisfied with using Octet String for string data and don't need
features like case-ignore matching.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 27 Jun 2003 13:29:11 -0700

Hallvard,

The way you worded your suggestion, the suggestion applies to all
currently prohibited characters.  That is problematic as prohibiting
certain assigned code points as well as all unassigned code points is
quite appropriate.  (Note that as code points are assigned, one can
update the profile to properly handle them.)

If you limit your suggestion to just private use code points, then
I think we might be able to change the algorithm such that those
points may be handled in a "local manner" (meaning that the
implementation may map, normalize, prohibit, bidi check,
insignificant character remove as they please) but we'd also
need to not only state some interoperability and security
considerations.

I don't necessarily support making such a change.  I offer it for
discussion purposes.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 27 Jun 2003 22:51:09 +0200

Kurt D. Zeilenga writes:
> currently prohibited characters.

Yes, I assumed that was the simplest way to do it.  Also:

> That is problematic as prohibiting certain assigned code points as
> well as all unassigned code points is quite appropriate.  (Note that
> as code points are assigned, one can update the profile to properly
> handle them.)

Assigned code points: OK.  I only know portions of Unicode, so I don't
know what all the code points are for.  I simply assumed that they are
there to be used, so someone who uses them may want to put them i LDAP.

Unassigned code points: Prohibiting them looks more problematic to me.
That means the server becomes obsolete when new code points are
assigned.  If one wants to use such new code points, it will then be
convenient if one can configure the server to not prohibit them.  One
won't get features like proper case folding, but at least one can but
them in the directory.

> I don't necessarily support making such a change.  I offer it for

Well, as you can guess, my vote is for it.  Or more:-)

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 27 Jun 2003 14:18:00 -0700

>won't get features like proper case folding, but at least one can but

I think its best we stick with versioning consistent
with Section 7.3 of RFC 3454.

>Well, as you can guess, my vote is for it.  Or more:-)

Noted.

Kurt