🚀 go-pugleaf

In article <726504366snz@mwassocs.demon.co.uk>, 
whyman@mwassocs.demon.co.uk (Tony Whyman) writes:

>>The recommendation to include the first letter of the G when the G is 
used
>>is silly. Ignore it.
>
>Yes, it is silly, but if you implement the standard ignoring it then a 
>conformance tester may label your implementation as non-comformant. If
>you really think it should be ignored then please send a defect report to 
>the CCITT.

I didn't take time to read the entire X.400, so I may have overlooked
something. X.402, 18.3.12 c) identifies "the initials of all his names
but his surname" as an optional piece of information out of the four 
that makes up a personal-name. So it looks as if - in principle - the
initial of the Givenname should be included. 

I am honestly surprised. There's a built-in redundancy, unnormalization
or whatever you call it - a built-in source of potential inconsistency.
Further, with this use of I a user interface cannot display a personal-
name by simply printing the G, I and S fields - it must match the
characters in I one by one to the words in G and remove those matching.

Also the "one letter per name" does not fit with all national languages
and conventions. Eg. in Norwegian, some names are conventionally
"initialized" using more than one character, such as "Per Christian Bull"
being written "Per Chr. Bull" or "Thorleif Hjeltnes" being "Th. Hjeltnes".
Very often this convention is followed when there is a mute letter, like
the h in Thorleif, or when one sound is written with two characters, like
the k sound written as Ch in Christian. If the inital is written the way
the user has always done it, a strict one-letter-per-name interpretation
would be wrong.

Note that "all his names" is not clearly defined. If these are intended
to all be included in G, then the I contains zero bits of information;
I feel that there is something objectionable in maintaining a 0-info
element. If there may be "names" specified nowhere, there is a rule
saying, in effect, "'I' may conatain anything as long as you don't
tell us from which info you derive it - if you tell us, we will catch 
you if you try to cheat us". No, that was not the intention with I.

I honestly think that the intention of the I field was to allow people
who don't usually write their name in full to use an (read: some) 
abbreviated form. I think the authors did not intend to prevent people
from writing their name the way they are used to. Quite to the contrary -
I think they explicitly want to honor accepted conventions.

Note that both G and I are optional, so you may use either your G+S, I+S 
and G+I+S. And also that a user may have multiple O/R-names - eg. one
in each of these three forms (and the Is don't have to be identical).
I won't believe that a conformance tester could rule an X.400 system 
non-conformant because it didn't detect "cheating" on the I attribute -
I have glanced through X.403 (MHS: Conformance testing) without seeing
anything pointing in that direction. 

There is a distinction between Directory name and an O/R address - a 
recipient may have multiple Directory names, eg. with different initials 
formats. Mappingfrom Dir name to O/R address is (as seen from X.400) a 
local matterthat should not influence open systems conformance. When you 
specify to the user interface a set of G, I and S attributes, are they to
be treated as a Dir name subject to directory lookup, or as an O/R 
address? I would definitely prefer the first, Dir name. Then the I
field cannot possibly be defined by X.400 conformance rules - only the
result of the directory lookup. But I can't believe that conformance 
or not of an X.400 system can be a function of data entered by a 
user into a directory system! So, the danger of being caught by a
conformance tester is very close to zero, in my understanding.

Another interresting observation is that the X.500 standard attribute
types (X.520) says nothing at all about any I attribute, as far as I
can see. Is it defined somewhere else (in the X.400 series?), or is
I simply not a standard attribute in the directory? (Obviously it can
be stored in X.500 as a non-standard attribute type - about the only
thing you cannot store in X.500 is hamburgers... :-) )

Maybe there is a reason to send a defect report to the CCITT about the 
lack of precise specification of the Initials attribute. But I think I
will wait to see the text of the 92 edition to get very upset about it.

Ketil Albertsen