[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Updating LDIF?
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
Mark C Smith wrote:
> 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