On 07.03.2017 15:41, Martin Babinsky wrote: > On Tue, Mar 07, 2017 at 04:34:42PM +0200, Alexander Bokovoy wrote: >> On ti, 07 maalis 2017, Simo Sorce wrote: >>> On Tue, 2017-03-07 at 09:38 +0100, Martin Babinsky wrote: >>>> On 03/06/2017 01:48 PM, Simo Sorce wrote: >>>>> On Mon, 2017-03-06 at 07:47 +0100, Martin Babinsky wrote: >>>>>> On 03/02/2017 02:54 PM, Simo Sorce wrote: >>>>>>> On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote: >>>>>>>> In this case it would probably be a good idea to think about "forward >>>>>>>> compatibility" and define a new AUX objectclass bringing in >>>>>>>> 'ipaDomainResolutionOrder' instead of extending two separate >>>>>>>> objectclasses. In this way we may the just extend whathever object we >>>>>>>> desire to carry the override in an easy and clean way. >>>>>>> I agree. >>>>>>> Simo. >>>>>>> >>>>>> Now the most difficult question remains... How to name this objectclass. >>>>>> I personally am out of ideas but will try my best to come up with >>>>>> something meaningful. >>>>> Try to describe what the option ultimately does with as few words as >>>>> possible. >>>>> >>>>> Simo. >>>>> >>>>> >>>> I was thinking about this and since we are performing name qualification >>>> (short-name -> fully-qualified name incl. domain/realm part), I would >>>> like to propose the following naming schema: >>>> >>>> objectlasses: ( OID_TBD NAME ipaNameQualificationData Desc 'data used >>>> for short name qualification data' SUP top AUXILIARY MAY >>>> (ipaNameQualificationDomainList) X-ORIGIN 'IPA 4.5' ) >>>> >>>> attributeTypes: ( OID_TBD NAME 'ipaNameQualificationDomainList' DESC >>>> 'List of domains used to qualify user short name' EQUALITY >>>> caseIgnoreIA5Match SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >>>> X-ORIGIN 'IPA v4.5' ) >>>> >>>> Let me know if you are ok with this or am I overengineering the names? >>>> >>>> I would like to solve this quickly so that I can finish the design and >>>> start implementation. >>> I was thinking that we can use acronyms here to make it less of a >>> mouthful and also more easily recognizable: >>> My idea is: >>> - ipaNameQualificationData -> ipaFQDNPolicies >>> - ipaNameQualificationDomainList -> ipaFQDNCheckOrder >> Sounds good to me. >> -- >> / Alexander Bokovoy > I am not sure about the relation of this to any policy, but I guess that is > just nitpicking. > > I will wait awhile for others to object and then update design. > I agree to not use "policy" in the name Martin^2
signature.asc
Description: OpenPGP digital signature
-- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
