[Date Prev][Date Next] [Chronological] [Thread] [Top]

FW: About aliases an X.500....




> -----Original Message-----
> From:	Harald Tveit Alvestrand [SMTP:Harald.Alvestrand@maxware.no]
> Sent:	Tuesday, April 07, 1998 4:57 PM
> To:	'Tim Howes'; Alan Lloyd; Alan Lloyd; ietf-ldapext@netscape.com
> Subject:	About aliases an X.500....
> 
> Alan,
> on a completely different topic:
> I've thought for a long time that using aliases is the only way
> one can sensibly use the distinguished name for uniqueness and for
> search scope limitation at the same time.
> Not sure about your view here - please explain
> 
> I think I have also got a fairly solid gut feeling for how it's being
> used
> (basically adding empty records of type "alias", with only the naming
> attribute; assuming that searches follow aliases encountered in a
> subtree traversal unless the appropriate control is invoked).
> 
> But I was trying to find supporting text for this picture in the X.500
> series when I came across this entry in X.501(93) 12.3.3:
> 
> >NOTE - The object class alias does not specify appropriate attribute
> types
> >for the RDN of an alias entry. Administrative Authorities may specify
> 
> >subclasses of the class alias which specify useful attribute types
> for RDNs
> >of alias entries.
> 
> Put this together with the fact that X.520 does not mention aliasing,
> 
> It does not because an alias is an OC and is specifed in 521 ie. alias
> is not an attribute as defined in 520 -  as you probably are aware
> 
> and that naming rules don't seem to give either permission or
> restriction
> on the use of RDNs for aliases, and it seems to me that the standard
> and
> its usage is somewhat underspecified.
> 
> I think its has been left flexible for the very purpose of being an
> alias to anything including an alias.
> 
> 
> I see two possibilities:
> 
> - The industry has ignored naming rules where aliases are concerned,
> and
>   is buliding products that "allow anything".
> The products generally permit one to use anything for alias name -
> generally Common Name but the structure rules (or content rules)  on
> the alias and target still apply.
>  ie adding an OC = alias under an OC = Org still has to be checked.
> 
> Or one can define aliased OCs as the alias entry that have a defined
> name type which usually corresponds with the name type of the target
> entry. Again structure rules apply.
> 
> All this flexibility and so simple to use :-)
> 
> On a more serious note we have an alias test script that tests all
> permutations of alias dereferencing that point within and out of and
> then back into the subtree of interest in search decomposition - I bet
> a few nested random aliases in some servers would give a few strange
> results.
> 
> - The industry is shipping private schemas that specify rules for how
> one
>   can use aliases, but these are not standardized.
> 
> Not sure of the point here - alias is a flexibility feature for long -
> solid name forms like file names or executables in PCs.
> 
>  we in our products permit through schema and structure defs, the
> organisation to do what they like.
> 
> Do these private alias schemes  really matter to the client software -
> these are just information views like those aliases as used on PCs to
> represent programs and desktop icons. The client just selects or
> navigates through them.
> X.500 should be seen as giving information services and views with the
> flexibility of those as provided on a PC .
> 
> And as for usage definition, these are defined in profiles or
> "organisational supplements" which define the naming policies of the
> org plus its schema usage.
> This is standard process when deploying directories - and usually
> takes a few hours/days.
> 
> Obviously, software developed to the two paradigms above will not
> necessarily
> interoperate.
> 
> Interoperation - why not.   from a DSA perspective they can both be
> administered under their respective structure rules. From a client
> perspective in search or browse  mode the client  is not impacted by
> the difference between common named alias and target entry name type
> alias - except for the icon displayed at the point of dereferencing.
>  However, this is really trivial.
> 
> Can you help me understand this one?
> 
> Hope this helps and let me know on the issues above.
> regards alan
> 
> 
> Regards,
> 
>                          Harald T. Alvestrand
> 
> Harald Tveit Alvestrand, Maxware, Norway
> Harald.Alvestrand@maxware.no