[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Updating LDIF?
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:
>
> 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: hahnt@us.ibm.com
> Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
> phone: 607.752.6388 tie-line: 8/852.6388
> fax: 607.752.3681
>
> Chris Ridd
> <chris.ridd@messagingdirect.com> To:
> Sent by: ietf-ldapbis@OpenLDAP.org
> owner-ietf-ldapbis@OpenLDAP.org cc:
> Subject:
> 05/03/2001 07:08 AM 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