Re: WG Last Call on URP I-D

I include an extract from an exchange between Ryan and Steven.  Ryan
notes that he would expect a delete of an attribute type to include all
subtypes as well.  I would have thought the same, but a check of
RFC2596 (Language Tags) shows:

   3.7. Modify Operation

   A client MAY provide a language code in an AttributeDescription as
   part of a modification element in the modify operation.

   Attribute types and language codes MUST match exactly against values
   stored in the directory.  For example, if the modification is a
   "delete", then if the stored values to be deleted have a language
   code, the language code MUST be provided in the modify operation, and
   if the stored values to be deleted do not have a language code, then
   no language code is to be provided. 

In other operations (e.g. compare, search results), giving the
attribute type DOES include all subtypes, but not for delete.

So if we are going to be consistent with other work on attribute
options (and 2596 seems to be the only RFC that discusses them in
detail), we should assume that a request to delete cn DOES NOT delete
cn;foobar.

Rick Huber

: 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.