[Date Prev][Date Next]
Re: Significance of name forms.
- To: email@example.com
- Subject: Re: Significance of name forms.
- From: dE <firstname.lastname@example.org>
- Date: Fri, 01 May 2015 11:35:32 +0530
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AqI70abb8kjfRzvW4gNPboSmOsKy0LE3LG9yZlcDF/M=; b=JZJmAj6QClnvpu+W5Ej7CIeZ52j4yU6mlQqOxJTmg/nCArDCmfX3av2ymlfKh761s3 yj0F7u+EqHkvratSAyKeQYmocN9wpjxjmeLBlLAcBdxsG575K+PAwf6UKmp6wGvAhdQW 7aNb7U9/89HpsQNEwmG7GbFhOUSElFSJR+OZ0LVuczrrAmQXFOHxUcLduaoTVxHYmAXP lIGguyBWEBmOoHO1Ok18ZHOOlvsZoD5HO5zB5Ts/MMr5IM7TfZ+YmPq/9WOEHLEmOgEh 5/OV/VuiJcQf4cUK3pD8h5OtpF2fXgLlsv/JSOGCc/pq6gW47kYHiO6NjOouqUpQ0g6m VNpQ==
- In-reply-to: <554276BE.email@example.com>
- References: <5541D66C.firstname.lastname@example.org> <554213E9.email@example.com> <firstname.lastname@example.org> <55422F1E.email@example.com> <firstname.lastname@example.org> <5542590D.email@example.com> <firstname.lastname@example.org> <55426EFA.email@example.com> <firstname.lastname@example.org> <554276BE.email@example.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
On 05/01/15 00:08, Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Now - nameForms only specify a structuralObjectClass that they
up to the DIT Structure Rule to define where in the DIT they take
But there is no reference from a DIT structure rule to the structural
object class. They are only associated via the name forms:
If you have a schema with multiple nameForms defined, and you take your
interpretation that nameForms take effect in the absence of DIT
Rules, then you get the nonsensical case of multiple nameForms
applying to a
Even if there is a governing structural rule for an entry there can be
more than one possible name form.
Irrelevant. There can only be one DIT Structure Rule for an entry, and
a DIT Structure Rule can only reference one nameForm. For any given
entry, only one nameForm may be in effect.
From X.501(1993) section 12.6.2:
If different sets of naming attributes are required for entries of a
structural object class, then a name form must be specified for each
distinct set of attributes to be used for naming.
Almost the same in X.501(2012) section 13.7.2.
And you (and others) agreed on that back in 2008:
Irrelevant. This references entries of a given structuralObjectClass
that exist in different parts of the DIT and thus governed by
different DIT Structure Rules.
> That is already explicitly prohibited in the spec.
Any implementation not supporting more than one possible name form is
=> Your argument is not sufficient.
Well in that case, it'll mean that that the DIT content rules will apply
only when referring to an entry which compiles with the name form; if
the same entry is referred to without compliance with the name form
(situation Z), the DIT structural rule will not apply. This means
inconsistency in the DIT. The DIT will be all about 'perspectives'. In
situation Z, an entry may not be subordinate to one entry, but in the
other, it will appear as subordinate.