RE: value v. representation

Kurt,

Kurt D. Zeilenga wrote:
> Section 5.3.4 ends with the sentence:
>   Whenever a CSN for some value is refreshed the value is
>   also refreshed using the exact value from the primitive
>   so that all directory servers use exactly the same
>   representation for the value. 
> 
> It should likely read:
>   Whenever a CSN for some value is refreshed the value is
>   also refreshed using the exact value from the primitive
>   so that all directory servers use the same value.  Each
>   server is, of course, free to represent the value
>   in any form allowed by the attribute's syntax.

I understand where you're coming from and I agree (it's what I meant),
but there is a definitional problem with the meaning of "exact value"
and "same value". Many people will interpret "same" to mean equal
according to the equality matching rule, but we're already talking
about a situation where URP has two values that are the "same"
according to the equality matching rule, but still not identical.

We understand that values exist in an abtract sense that is
independent of which encoding (e.g. native LDAP or binary) is used
to transfer them in protocol. Since a server could be storing values
in any of the possible encodings, or in some other entirely different
format, it is not appropriate to just test whether two values have
the same series of octets. We need a definition of "identical" that
is more fundamental than the usual equality matching rules and that
does not depend on the transfer encoding.

It occurs to me that the allComponentsMatch matching rule from
draft-legg-ldapext-component-matching-03.txt provides a reasonable
and well-defined test for the identicality of values that is
independent of transfer encoding. If I make use of this definition
in URP then the last sentence of the first paragraph in Section 5.3.4
could be reworded like this:

  "Whenever a CSN for some stored value is refreshed, the stored
   value itself is also refreshed using the value from the primitive
   if the stored value and primitive value are not identical.
   For the purposes of the procedures described in this document,
   two values are considered identical if they compare TRUE
   according to the allComponentsMatch matching rule defined
   in [CMR]. The purpose of refreshing stored values is so that all
   directory servers converge to the exact same abstract value.
   Each server is, of course, free to represent the value using any
   transfer encoding defined for the attribute's syntax."

[CMR] being a reference to the component matching rules draft.

The final paragraph in the section also needs to be reworded.

   A stored value that is replaced by the value from a primitive
   retains its distinguished or non-distinguished status. This
   includes replaced values of single-valued attribute types.

> 
> Replicas must converge to the same value, not to the same
> representation of that value.  Note: CN value 'Foo Bar'
> is not the same value as CN 'Foo  Bar' though they
> equal per the equality rule.  Replicas must converge to
> one or the other (per URP).  However, a member
> value of 'CN=Foo Bar' is the same as CN='Foo\20Bar'; no
> change is required by either replica.
> 
> That is, URP must not force one replicas preferred form
> upon another server.

I totally agree.

> 
> BTW, the URP seems to be dependent upon having an EQUALITY
> rule defined for each attribute type and for each replica
> to implement this rule.  What happens when the attribute
> does [ not ] have an EQUALITY matching rule?

Good question. I will have to add some text to cover this situation.

The simple solution is to regard all values of such an attribute
as being different. This would mean that stored values and values
in a primitive are never considered equal, so duplicate values
with different CSNs could accumulate in the attribute and the
p-remove-attribute-value primitive will be ineffectual. However, if
the servers are playing by the rules they should not be allowing
clients to add or remove individual values of the attribute. The
only permitted changes are to add, remove or replace the entire
attribute. Therefore, except when values are first added to an
attribute, there will be a p-remove-attribute primitive immediately
prior to the p-add-attribute-value primitives for the added values,
and only the values of the latest (by CSN) add or replace will
appear in the attribute.

It is possible that values could be simultaneously initially added
to the previously non-existent attribute at two separate replicas,
which would eventually lead to both sets of values appearing in the
attribute. We can fix it so that only the set with the latest CSN
appears in the attribute but it is hard to say which is the more
desirable outcome, so I don't propose to "fix" it. The same effect
will be achieved anyway if clients always use the replace alternative
on attributes without an equality matching rule.

> or one replica implements
> the rule and another doesn't?

This is just one of many possible functional inconsistencies or
differing levels of conformance that will thwart URP, or LDUP in
general. There is an obvious requirement that servers should
only be replicating between themselves the attributes and entries
to which they are equally capable of applying URP and the other
LDUP procedures.

The possible cases are innumerable, and it is mostly an issue of
what can be usefully specified in replication agreements, so I don't
intend saying anything about this in the URP document, and I'm
not going to attempt to define what "equally capable" means.

> 
> Kurt
> 
> 

Regards,
Steven