Subject: Re: Updating LDIF?

From: "Timothy Hahn" <[email-masked]>
Date: Thu, 3 May 2001 15:04:16 -0400

Chris,

In my experience, the attribute type after the modify directive 
(add/replace/delete) is often ignored (except in the case of delete) since 
the attribute to modify is contained on subsequent lines.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Chris Ridd <[email-masked]>
Sent by: [email-masked]
05/03/2001 07:08 AM

        To:     [email-masked]
        cc: 
        Subject:        Updating LDIF?

Is anyone looking at updating RFC 2849, the LDIF spec? The perl-ldap
authors have observed a minor problem with change records that they would
appreciate  some clarification on.

The problem is that the attribute described on the add/delete/replace 
lines
is permitted in the BNF to have options. It isn't clear how these options
are meant to relate to the options defined in the subsequent lines 
defining
attribute values to add.

This fragment:

dn: uid=foo, dc=example, dc=com
changetype: modify
add: telephoneNumber;work
telephoneNumber;home: 1234 

does not appear to make sense because the added value is a home phone
number and not a work one, and the ;home attribute is not necessarily a
subtype of the ;work attribute. It is however permitted by RFC 2849.

Is it sensible to require the attribute on the add/delete/replace to be a
supertype of all the subsequent attributes?

Or is it sensible to simply ignore any options specified on the
add/delete/replace?

Cheers,

Chris

---

From: [email-masked] (Mark C Smith)
Date: Thu, 03 May 2001 15:58:52 -0400

I agree with Tim, but this it would be useful to clarify this in the
LDIF specification, e.g., what should a parser of an LDIF document do if
the two AttributeDescriptions do not match?

Note that this is well outside of the LDAPBis charter.  I copied Gordon
Good so he is aware of this issue.

-Mark

Timothy Hahn wrote:
> (add/replace/delete) is often ignored (except in the case of delete)
> since the attribute to modify is contained on subsequent lines.
> 
> Regards,
> Tim Hahn
> 
>  Chris Ridd
>  <[email-masked]>              To:
>  Sent by:                               [email-masked]
>  [email-masked]               cc:
>                                                Subject:
>  05/03/2001 07:08 AM                    Updating LDIF?
> 
> 
>

---

From: Gordon Good <[email-masked]>
Date: Thu, 03 May 2001 21:44:48 -0700

Actually, the ABNF would allow something even goofier like:

changetype: modify
replace: mail
cn: Mark C. Smith

wouldn't it? I'm not aware of any way to express the needed restriction in
ABNF, so I would suggest adding a note.

My feeling is that implementations SHOULD reject such a change record if
they encounter it in an LDIF file. Implementations MUST NOT generate a
change record that names different attribute types or subtypes within a
single change-add, change-delete, change-modify, or change-moddn element.

Make sense?

I'll file this away for inclusion in the next revision.

-Gordon