RE: WG Last Call on URP I-D

["Steven Legg" <steven.legg@adacel.com.au>]

Ryan,

Ryan Moats wrote:
> On Wed, Sep 05, 2001 at 07:34:41PM +1100, Steven Legg wrote:
> |
> | Ryan,
> |
> | Ryan Moats wrote:
> | > What I seemed to miss was the discussion of primitive generation
> | > with respect to attribute types, attribute subtypes and
> | > attribute options.
> | > Specifically there was no clarification
> | >
> | > - whether attribute subtypes and options were or were not
> | > supported.  I
> | >   believe absense of a restriction means they are, but others
> | > could read
> | >   absense of a restriction to mean they are not.
> |
> | The absence of any clear direction in URP on subtyping issues is an
> | oversight. I had been assuming that attribute subtyping is basically
> | ignored by URP, as is the case for updating in general and for X.500
> | replication updates in particular. I shall add words to the URP
> | document to the effect that attribute types in a subtype hierarchy
> | are treated as distinct and unrelated types by URP.
> |
> | Attribute options are a different matter since RFC 2251 isn't clear
> | about how this form of subtyping applies to updates. For example,
> | does a request to delete the cn attribute also delete the cn;foobar
> | attribute ? If I can assume that the answer is no then I can just
> | say that attribute types with options are also treated as distinct
> | and unrelated types by URP. The alternative answer will require more
> | extensive changes.
>
> Hmm, I would think that principle of least surprise would say that
> deleting cn wouls also delete cn;foobar.  I'd like to hear what
> others think of course.

What is surprising depends on your user. Someone who is familiar
with X.500 attribute subtyping where subtypes are ignored for updates
might be surprised that option subtypes are not ignored in LDAP updates.

It is also surprising when values that weren't explicitly mentioned
get deleted. Implicit deletion of anything is generally undesirable.

Also consider that a request to remove just the cn value from an entry
would require a delete and an add to put back the cn;foobar value.
It is safer and cleaner to require that clients explicitly remove
each option-subtyped value than to rely on them putting back any
implicitly deleted ones.

Deleting only the values of the nominated attribute options also
side-steps questions of single versus multiple inheritance of options.
For example, it avoids the need to know whether cn;foo;bar is a subtype
of cn;bar.


> | > - whether or not dsaOperation types could be replicated. Since the
> | >   requirements draft states this as a MUST NOT (req G10), the lack of
> | >   a discussion in the primitive generation portion of the document
> | >   disturbs me.
> |
> | URP doesn't go into any detail about what is or isn't part of the area
> | of replication since that is in the scope of another LDUP document and
> | that document isn't yet ready to go to last call. URP just has a blanket
> | statement that replication primitives are generated only for directory
> | contents that are covered by the replication agreement, so it will
> | automatically conform to whatever the final LDUP model document says.
> | If the model draft says that dsaOperation types are never part of a
> | replication agreement then URP will never replicate that kind of
> | operational attribute and requirement G10 will be satisfied.
> |
>
> I *think* I may have found the blanket statement:
>
> (in section 5.2, first para, last sentence)
>
> "No replication primitives are generated for entries or entry contents
> that are outside the scope of the replication agreement."
>
> Is this indeed it?

It is.

> If so, I missed it the first time through and
> I'd suggest that it be made its own paragraph (along with the supporting
> text of 5.3) to make it more obvious.

It's easy enough to make it a separate paragraph but it's not clear
to me what you regard as the supporting text of 5.3.


Regards,
Steven