<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 04/29/2014 10:07 PM, Martin Kosek
      wrote:<br>
    </div>
    <blockquote cite="mid:5360068E.80805@redhat.com" type="cite">On
      04/29/2014 08:17 PM, Simo Sorce wrote:
      <br>
      <blockquote type="cite">On Tue, 2014-04-29 at 20:00 +0200, Petr
        Viktorin wrote:
        <br>
        <blockquote type="cite">This adds the "idnsSecInlineSigning"
          attribute and related option.
          <br>
          <br>
          <a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/3801">https://fedorahosted.org/freeipa/ticket/3801</a>
          <br>
          <br>
          Simo, is adding a MAY attribute to an existing objectClass
          okay?
          <br>
          <br>
        </blockquote>
        <br>
        Not unheard of, however in the past we discovered some schema
        <br>
        replication issues that may have an impact, let's make sure DS
        team also
        <br>
        agrees this is not going to cause issue.
        <br>
        <br>
        <blockquote type="cite">From a purely functional pov a MAY
          attribute will not break any stored
          <br>
        </blockquote>
        object, so it is fine.
        <br>
        <br>
        Simo.
        <br>
      </blockquote>
      <br>
      Adding Thierry to the CC list to evaluate the risks, he was
      already involved in fixing related issue in the DS for a similar
      Dogtag schema extension.
      <br>
    </blockquote>
    <font face="Times New Roman, Times, serif">Hello,<br>
    </font><br>
    <blockquote><font face="Times New Roman, Times, serif">When an
        instance in the topology contains schema extensions like new MAY
        attribute, this extension would be propagated to all instances
        by replication (no need to copy/merge schema files). This was
        the purpose of </font><font face="Times New Roman, Times,
        serif"><font face="Times New Roman, Times, serif"><a class="moz-txt-link-freetext" href="https://fedorahosted.org/389/ticket/47721">https://fedorahosted.org/389/ticket/47721</a>.
          So it is fine to add new MAY/MUST attribute or new
          attribute/objectclasses.<br>
          <br>
        </font>During a replication session, a master will check what
        schema definitions (objectclasses/attributes) of the replica
        extends its own schema. If such definitions exist the supplier
        add/replace them in its schema and its user99.ldif file. In your
        case if a replica contains a new allowed attribute (e.g. </font><tt>'</tt><tt>idnsSecInlineSigning'</tt><font
        face="Times New Roman, Times, serif"><tt>)</tt> but not the
        supplier then the supplier 'learns it' (during a replication
        session it initiated) and so an entry containing that new
        attribute can be updated on the supplier as well.<br>
        There is a similar mechanism, when a replica receives a schema
        that contains new definitions, it 'learns' them.<br>
        <br>
        The fix for 47721 is introduced in 389-ds 1.3.2.17 and after.<br>
        It was tested with mixing 1.3.2.17 instance with legacy versions
        (1.3.1, 1,3.0..), and the schema on both side converged to a
        common one. This, whatever if the extensions are present on both
        side. <br>
        A limitation is that a legacy instance (not having the fix),
        must have a replica agreements to/from an instance with the fix.<br>
        <br>
        regards<br>
        thierry<br>
      </font><br>
    </blockquote>
  </body>
</html>