Subject: DN-alt issues

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 17 Aug 2002 13:58:29 -0700

I've been thinking through the alternative DN approach.
Basically, I've tried to find a way to rework the Section
2.3 table restriction such that any registered descriptor
could be used.  I, however, haven't found a way to do so
without creating future interoperability problems,
causing breakage of existing implementations, or other
problems.

Maybe somebody else can.  I'd be happy to assist anyone
who is willing and able to author an alternative approach.

The current I-D says:
  Implementations MUST recognize AttributeType string type names     
  (keywords) listed in the Section 2.3 table, but MAY recognize other
  names.  Implementations MAY recognize other DN string representations
  (such as that described in RFC 1779). As there is no requirement
  for other names or alternative DN string representations to be
  recognized, implementations SHOULD only generate DN strings in
  accordance with Section 2 of this document.

That is, the current I-D allows other descriptors to be used
in DNs.

Unless we state that only registered descriptors can be
used in DNs and any descriptor not known to be registered by
an implementation is to be treated as unrecognized, we won't
gain anything.  And even if we adopt these restrictions,
we'd still have to recommend against use of descriptors
not in the 2.3 table as an implementation cannot assume that
all other implementations will recognize other descriptors
(registered or not).

Basically, changing "other names are not recommended" to
"registered names are not recommended" does not buy us anything.
We'd still have to recommend against use of any name not
in the 2.3 table to prevent interoperability problems.

So, I think we need to go back and study why the change
is desired its proponents to see if there is another way
to address the issue they raise.  In reviewing past discussions, 
I find that proponents of the change raise user interface
(presentation) issues, not protocol issues.

The RFC 2253 DN representation, unlike the one provided by
RFC 1779, is not intended to be presented to users without
translation.  RFC 2253 describes the on-the-wire representation
of a DN.

It's my personal opinion that these presentation issues, while
interesting, shouldn't be resolved by changing the on-the-wire
representation.  This would only cause interoperability problems.
The presentation issues should be resolved above the protocol,
by a presentation layer.

I do, however, believe some clarifications to the current
I-D are needed.  In particular, the I-D should clearly state
that the table is not extensible. 

It might also be appropriate to discuss the most basic of
presentation of RFC 2253 DN issues (because, like it or not,
some users (especially admins) have to deal with DN strings
at times).  Basically, the I-D should say that where DN strings
are presented to users, they are to be treated as an identifier
(like a URI) and not mucked with.

I also have a one or two unrelated clarifications which I
like the WG to consider (to resolve issues which only recently
came to my attention).  I summarize these in a separate thread.

Kurt

---

From: Scott Seligman <[email-masked]>
Date: 19 Aug 2002 11:27:44 -0700

> that the table is not extensible. 

I've seen all the old e-mail, I know it's been hashed to death, I
respect Kurt's opinions and don't expect to change his mind, but
RFC 2253 (section 2.3, second paragraph) clearly indicates that the
table *is* extensible.  The table in the RFC itself is described as 
"an example ... for a few of the attribute types", and the extension
mechanism is (vaguely) described as "a published table... associated
with LDAP [RFC 2252]".  Perhaps extensibility is a bad idea, and
perhaps the extensibility mechanism as spec'ed is inadequate (though
no more so than for syntaxes), but the spec says what it says.  It is
inappropriate to change this in a BIS update, where the goal is
clarifying an existing spec, not designing a better spec.

Scott

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 19 Aug 2002 12:46:22 -0700

At 11:27 AM 2002-08-19, Scott Seligman wrote:
>It is inappropriate to change this in a BIS update, where the goal is

I don't think we've redesigned the DN string representation.
The representation still allows arbitrary type name strings
to be used.

We've added recommendations which narrow the use of a
particular feature to improve interoperability between
independently developed implementations.  This addition,
IMO, is quite appropriate.

Kurt

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 21 Aug 2002 02:05:32 -0700 (PDT)

On 19 Aug 2002, Scott Seligman wrote:

> respect Kurt's opinions and don't expect to change his mind, but RFC
> 2253 (section 2.3, second paragraph) clearly indicates that the table
> *is* extensible.  The table in the RFC itself is described as "an
> example ... for a few of the attribute types", and the extension
> with LDAP [RFC 2252]".  Perhaps extensibility is a bad idea, and perhaps
> the extensibility mechanism as spec'ed is inadequate (though no more so
> than for syntaxes), but the spec says what it says.  It is inappropriate
> to change this in a BIS update, where the goal is clarifying an existing
> spec, not designing a better spec.

If the "published table" had been well-established and had actually been
extended since 2252 was published, then we wouldn't be talking about
changing its nature.  But it's the lack of clarity on what the table is in
the first place that's the reason we're discussing it.  Deciding that a
table that in practice has never been extended is now by definition
non-extensible is within scope, in my opinion.

 - RL "Bob"

---

From: [email-masked] (Mark C Smith)
Date: Wed, 21 Aug 2002 10:04:47 -0400

> non-extensible is within scope, in my opinion.

I agree, but we could also agree on a new definition for the table. Our 
goal is clarity and interoperability, but we also do not want to 
retroactively label a lot of LDAP deployments as "non standard" if we do 
not have to. One  approach would be to say that strings may be used in 
DNs instead of OIDs for any attribute type that is defined in a document 
that is part of the LDAP technical standard. That would widen the 
"table" to, for example, include attribute types from 
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-user-schema-02.txt.

Note that this does not pull in all of the types that the PKIX group 
wants to use in DNs, and that there may still be interoperability issues 
because most of the types in the user schema draft are categorized as 
SHOULD recognize while use of strings for the types listed in the small 
table that is currently in the DN representation draft is in my opinion 
mandatory (although the word MUST is not used; the actual wording is "If 
the AttributeType is in the following table ... then the type name 
string from that table is used...").

-- 
Mark Smith
Netscape Directory Product Development
My words are my own, not my employer's.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Aug 2002 07:40:06 -0700

At 07:04 AM 2002-08-21, Mark C Smith wrote:
>I agree, but we could also agree on a new definition for the table. Our goal is clarity and interoperability, but we also do not want to retroactively label a lot of LDAP deployments as "non standard" if we do not have to.

draft-ietf-ldapbis-dn causes, to the best of my knowledge, to
become "non standard".

>One  approach would be to say that strings may be used in DNs instead of OIDs for any attribute type that is defined in a document that is part of the LDAP technical standard.

This is already allowed in draft-ietf-ldapbis-dn,
just not recommended (due to interoperability reasons).

  Implementations MUST recognize AttributeType string type names
  (keywords) listed in the Section 2.3 table, but MAY recognize
  other names. Implementations MAY recognize other DN string
  representations (such as that described in RFC 1779). As there
  is no requirement for other names or alternative DN string
  representations to be recognized, implementations SHOULD only
  generate DN strings in accordance with Section 2 of this document. 

That is, "FOO=foo,BAR=bar" is a valid LDAPv3 DN string.
However, this form is not recommended for the reasons
discussed in Section 5.3.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Aug 2002 07:53:56 -0700

>draft-ietf-ldapbis-dn causes, to the best of my knowledge, to

I meant:
        draft-ietf-ldapbis-dn causes, to the best of my knowledge,
        no existing implementation to become "non standard".

---

From: [email-masked] (Mark C Smith)
Date: Wed, 21 Aug 2002 13:24:13 -0400

>         no existing implementation to become "non standard".

OK. But if I take the word "generate" to include "send on the wire" than 
I know of implementations that violate this statement from 
draft-ietf-ldapbis-dn:

   As there is no requirement for
   other names or alternative DN string representations to be recognized,
   implementations SHOULD only generate DN strings in accordance with
   Section 2 of this document.

That is, some implementations such as the Netscape Directory Server will 
generate (send) DN strings that use attribute type names that are not 
listed in the table that is in section  2.3 of the draft. These 
implementations just send back whatever DN was stored at the time 
entries were created, which is in fact what most users expect.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Aug 2002 11:44:21 -0700

At 10:24 AM 2002-08-21, Mark C Smith wrote:
>That is, some implementations such as the Netscape Directory Server will generate (send) DN strings that use attribute type names that are not listed in the table that is in section  2.3 of the draft. These implementations just send back whatever DN was stored at the time entries were created, which is in fact what most users expect.

draft-ietf-ldapbis-dn doesn't prohibit this behavior.

---

From: Scott Seligman <[email-masked]>
Date: 25 Aug 2002 03:46:25 -0700

"Kurt D. Zeilenga" <[email-masked]> writes:
>> That is, some implementations such as the Netscape Directory Server
>> will generate (send) DN strings that use attribute type names that
>> are not listed in the table...
>

The draft requires some editing to clarify this point.  In the section
on "Converting DistinguishedName from ASN.1 to a String" there is no
mention that this behavior is allowed.  This is where that information
needs to be presented.  In the following section "Parsing a String
back to a Distinguished Name" it does say "implementations SHOULD only
generate DN strings in accordance with Section 2", but this is
logically the wrong place to give this guidance.  Also it doesn't
precisely specify the manner in which implementations are free to
deviate from the recommendation of Section 2.  Not that it's
complicated or even non-obvious, but as this is a spec, Section 2 must
precisely specify what's allowed in addition to what's recommended.

Second, Netscape is not the only server to do this.  Adding a
"SHOULD NOT" restriction against a common (majority?) practice seems
like it may be taking things too far for a BIS update.  Legalistically
you may be covered, but this is a matter of degree.  What percentage 
of servers deployed today would you estimate violate the new policy,
as Mark describes for Netscape?

Note that I'm not questioning the existence of interoperability issues
relating to attribute type string names, and I do support the draft
giving clear guidance on this.

Scott Seligman
Java Security, Networking, and Naming
Sun Microsystems

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 25 Aug 2002 21:28:01 -0700

At 03:46 AM 2002-08-25, Scott Seligman wrote:
>The draft requires some editing to clarify this point.

How about if the Section 2 paragraph:
  The following sections define the RECOMMENDED algorithm for
  converting from an ASN.1 structured representation to a UTF-8
  [RFC2279] string representation. 

were followed by:
  Other documents may describe other algorithms for converting a
  distinguished name to a string, but only strings which conform
  to the grammar defined in Section 3 SHOULD be produced by
  LDAP implementations.

SHOULD here for consistency with Section 3 requirements.

This would not only clarify that other algorithms may be
documented, but also clarify that those algorithms are
restricted to the Section 3 grammar.

I see no reason to single out additional short names.  Other
algorithms may differ from the recommended algorithm in a
number of ways.  We don't need to enumerate all the differences
which are allowed, we need state which differences are not
allowed.

>like it may be taking things too far for a BIS update.

RFC 2026: 
   Implementors should treat Proposed Standards as immature     
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

>giving clear guidance on this.

Noted.

Kurt