Re: [Fwd: Re: Approved: draft-ietf-policy-core-schema-16.txt]

Kurt D. Zeilenga wrote, On 04/21/03 15:08:
> Larry,
> 
> Like any other RFC-to-be, draft-ietf-policy-core-schema
> has to wait on its normative references.
> 
> draft-zeilenga-ldap-user-schema is still an active "work
> in progress" ("expire" dates can be misleading as "in process"
> I-Ds don't expire).  See the I-D data tracker for current
> status.


Thanks for that distinction, Kurt. I was working from the apparently
mistaken assumption that expiration was the end of the line for an
I-D unless a subsequent version kept it fresh and active.

Thanks also for pointing me to the I-D data tracker. I was unaware
of the wealth of information there.


> 
> draft-zeilenga-ldap-user-schema appears (from the available
> I-D data tracker details) to have been approved by the IESG.
> So this thread seems moot.


Kurt, I hope it *is* moot, and that the attainment of RFC status
by your draft really does move the PCLS rapidly toward publication
as an RFC.

I guess I'm an impatient sort. When we trace the PCLS back to its
DEN (Directory Enabled Networks) roots, it's fair to say that it
has been a work in progress for more than five years. That might
not seem a long time to a standards author. But for rest of us...


> 
> 
>>This situation can be remedied by a minor edit of the PCLS draft.
> 
> 
> No.
> 
> PCLS defines elements of LDAP schema dependent on LDAP
> matching rules which, at present, are not specified
> in any standard track document.  While X.520(93) defined
> X.500 corresponding matching rules, it does not define
> any LDAP matching rules.


Agreed.


> As X.500 matching rules have
> to be adapted for use in LDAP (as demonstrated in RFC
> 2252), referencing X.520 is not sufficient.


On the surface, "adapted for use in LDAP?" looks like a hard
question. PCLS uses three matching rules which haven't been
explicitly defined as standard LDAP matching rules. They are
booleanMatch, integerOrderingMatch, and octetStringOrderingMatch.

What does "adapted for use in LDAP" mean for those matching rules?
According to draft-zeilenga-ldap-user-schema, the "adaptation" is
little more than a restatement of the X.520 definitions. That's fine.
It's enough. Explicitly defining them in the LDAP context is
important, to be sure. I expect that there are other matching rules
which require some considerable profiling to adapt their semantics
and behavior from X.520 to LDAP. But these three obviously aren't
among them.

Some LDAP-conformant server implementations already support
booleanMatch, integerOrderingMatch, and octetStringOrderingMatch, in
conformance with their X.520 definitions. Does it matter that these
X.520-defined matching rules are not yet defined in an LDAP-specific
RFC? The server doesn't care. The schema doesn't care. The applications
which use the server and the schema don't care, either.

Rough consensus and working code, right? I realize that Kurt, the
the ldapbis WG, and the IETF are working very hard to make LDAP more
concise, precise, and complete. This is Good Work. But in the case of
the PCLS and these three matching rules, if the subject of the
normative reference at issue here isn't immediately forthcoming,
there really isn't a good reason for PCLS to wait any longer.


> 
> The PCLS's normative reference to draft-zeilenga-ldap-
> user-schema is correct and proper.  No action is needed
> by the Policy WG.


I agree with "correct and proper", but I'm not convinced of
"necessary".

If draft-zeilenga-ldap-user-schema is really on the cusp of RFC-hood,
then the PCLS should simply follow its present course. This is
certainly the path of least resistance.

But if draft-zeilenga-ldap-user-schema slips off the cusp, PCLS should
defer to pragmatism, drop the reference, and move on.


-- 
--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  [email protected]      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|