Subject: Re: WG Last Call on URP I-D

From: [email-masked] (Richard V Huber)
Date: Wed, 5 Sep 2001 11:11:11 -0400

Yes, that is why I said that I originally thought a reference to the
type would include all subtypes for a delete.  But 2251 does not go
into detail on what it MEANS to be "treated as a "subtype of the
attribute type without any options".  RFC2596 is a standards track RFC
that does provide detail on treatment of attribute options, at least
for the specific case of language tags.

I don't think we want to be in a situation where we say "a delete of an
attribute type includes all subtypes unless the subtype begins with
'lang-' in which case the rules of 2596 apply".  We need to treat all
attribute options, including language tags, consistently (with possible
exceptions for tags like ;binary).

Is LDAPBIS going to reissue 2596?  How do we deal with the
inconsistency?

Rick Huber

: From [email-masked] Wed Sep  5 10:30:28 2001
: Return-Path: <[email-masked]>
: X-Sender: [email-masked]
: To: [email-masked] (Richard V Huber)
: From: "Kurt D. Zeilenga" <[email-masked]>
: Subject: Re: WG Last Call on URP I-D
: Cc: [email-masked], [email-masked], [email-masked]
: Mime-Version: 1.0
: 
: RFC2251:
:    An AttributeDescription with one or more options is treated as a
:    subtype of the attribute type without any options.
: 
: Of course, ;binary is a bit of an exception to this.  LDAPbis
: is working on clarifications.
: 
: Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 05 Sep 2001 09:25:06 -0700

At 08:11 AM 2001-09-05, Richard V Huber wrote:
>attribute type without any options".

I believe it means that 'cn;foo' is to 'cn' as 'name' is to 'cn'.
Hence, deleting 'cn' would NOT delete 'cn;foo'.  I believe 2596
is consistent with this interpretation.

>Is LDAPBIS going to reissue 2596?

It's not a charter item.  I would suspect the authors would
revise this based upon clarifications to LDAPv3 produced
by LDAPbis and language tag clarifications already published.

I note that LDAPbis is considering the impact of changes it
proposes upon this and other extensions.

>How do we deal with the inconsistency?

Well, the primary inconsistency is that we currently have
two different semantics for options:
        1) most options act as subtypes
        2) transfer options (;binary) don't act as subtypes

I've heard two different suggestions to deal with this:
        a) detail two kinds of options
        b) axe transfer options

Currently, LDAPbis is attempting a).

If you have comments in this area, I suggest they be directed
to the LDAPbis list.