Subject: attribute options

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 07 Mar 2005 11:31:57 +0100

I found some old problems with attribute options in the arcive:
(Thread 'Active Directory question', Apr 2004)

Option definitions are not part of the (standardized) schema.  So may
an option name, like an attribute name, have different meanings in
different parts of the DIT - in the same server?  That is not my
impression, but it must be possible if shadowing of entries in general
is to be possible.  (E.g. shadowing from two different servers which
support different attribute options).  Also a client which talks to
two such servers may need to treat them as part of the schema.

Maybe [Models] should clarify how that works, or refer to whatever X.500
says about it.

Models 2.5 (Attribute Descriptions) says:
>  An attribute description with an unrecognized attribute type is to be
>  treated as unrecognized.  Servers SHALL treat an attribute description
>  with an unrecognized attribute option as unrecognized.  Clients MAY
>  treat an unrecognized attribute option as a tagging option (see
>  Section 2.5.2.1).

However, it does not say that clients MAY treat an unrecognized
attribute option as anything _else_ than a tagging option - e.g. treat
the attribute description as unrecognized.

Problem with the ";binary" option:
A pre-LDAPbis server may send a value with an unsolicited ";binary"
option (and with non-textual syntax).  A post-LDAPbis client need not
recognize ";binary", so it MAY treat it as a tagging option - and thus
parse the binary attribute value according to the attribute's
string-based syntax.
Maybe the caveat should be added that clients SHOULD NOT treat ";binary"
as a tagging option.

While I'm writing, a question: Am I right in assuming that the spec of
any option, including a tagging option, may include mandatory
server-specific functionality and (due to the "Clients MAY... above)
client-specific optional functionality, so that at least a server cannot
necessarily support a tagging option merely by recognizing its name?

-- 
Hallvard

---

From: Steven Legg <[email-masked]>
Date: Tue, 08 Mar 2005 11:11:48 +1100

Hallvard,

Hallvard B Furuseth wrote:

> different parts of the DIT - in the same server?

All the options I am aware of have the same meaning everywhere. I don't
think we should allow the definition of an attribute option whose meaning
is different in different parts of the DIT.

 > That is not my

The fifth edition of X.500 will map LDAP attribute options into contexts,
but beyond that will defer to LDAP with regard to their meaning.

> Maybe the caveat should be added that clients SHOULD NOT treat ";binary"

There isn't a specification of ";binary" that is at the required level of
standard maturity for ldapbis to be able to reference it. I think we should
drop the "Clients MAY" and perhaps change the "Servers SHALL" to
"Implementations SHALL".

> necessarily support a tagging option merely by recognizing its name?

Well, ";transfer-ber" is an example with mandatory server and client functionality
which requires servers to do more than recognize the name. An option with mandatory
server functionality and optional client functionality is allowed in principle but
I'm not aware of any actual examples.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 08 Mar 2005 07:56:59 -0600

>is different in different parts of the DIT.

I agree.  But that said, I don't it appropriate for [Models] to
place such a restriction on the scope of extension possible via
options.

I do note that server do not necessarily have to support each option
for each attribute type and/or for all fragments of the DITs.  For
instance, ;binary support can be limited to say only those attribute
types where ;binary use is required.  Likewise, a server's
;lang-X support could be limited to entries (e.g., not supported in
subentries).  Or a client could only deal with language tags only on
name and its subtypes.

Of course, there are issues of option support discovery.  These
are left to specifications of options to address.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 8 Mar 2005 15:41:31 +0100

> is different in different parts of the DIT.

We do: Private options with names starting with "x-".  I should have
clarified that.  Which would also have given me the answer to my
concern with replicating from two servers with such conflicting options:

Private options are the inventor's problem.

>> (...)

I would be sorry to see the "Clients MAY..." disappear as you suggest
but given your reply the current situation isn't good either.  I think
I'll stick to "no opinion" on this one...

> Well, ";transfer-ber" is an example with mandatory server and client
> functionality which requires servers to do more than recognize the
> name. An option with mandatory server functionality and optional client
> functionality is allowed in principle but I'm not aware of any actual
> examples.

-- 
Hallvard