Re: schema syntax: Octet string vs IA5 string

[Roel van Meer <rolek@linvision.com>]

"Kurt D. Zeilenga" wrote:
> 
> At 07:50 AM 2001-11-29, Roel van Meer wrote:
> >"Kurt D. Zeilenga" wrote:
> >> At 03:53 AM 2001-11-29, Roel van Meer wrote:
> >> >in my schema, i have an attribute which will contain an ip number.
> >> >Should this have an Octet String syntax, or an IA5 String syntax?
> >> >
> >> >Logically, i would say it should be an octet string, but the nis
> >> >schema uses an IA5 string.
> >>
> >> Logically, I'd say it should be ipAddressSyntax (fictitious) which
> >> constrained the value to an IP address and defined an appropriate string
> >> syntax.
> >But in absence of this syntax...
> 
> The syntax and matching rules of an attribute need to be chosen
> carefully based upon the intended use in applications of the
> attribute type.  Having zero clue as to how you intend to use
> this attribute type, I frankly cannot not make a recommendation
> on which syntax and matching rules are most appropriate.

Please forgive me being ignorant about this. The attribute will have an
IP address as its value, and i will only do equality matching on it.
Assuming this, i thought i had two choices, octet or IA5 string. When i
found out that the directory server doesn't check if the value you give
is actually matching your syntax (i can put a random string in an octet
string attribute), the only two criteria i had were performance and
logic.

Logically, i would say the octet string syntax matches the IP address
syntax the closest.

About performance, i couldn't say anything.

> >And if it does matter, do you know which one would be best?
> 
> I would say it matters more to design the schema to meet the
> application needs then to worry about what are minor influences
> to the performance of the directory server.

Very true. The thing that brought me to thinking about performance is
that i have no idea how the application needs could be enforced by the
schema.

Obviously, my knowledge about schema creation lacks short. Can you
recommend something to read or a good book to buy?

Regards, thanks for your time,

rolek

--
1A First Alternative rolek@alt001.com    www.alt001.com
Linvision BV         rolek@linvision.com (www|devel).linvision.com
--