home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / iso / x400 / 758 < prev    next >
Encoding:
Internet Message Format  |  1993-01-10  |  5.0 KB
  1. Path: sparky!uunet!spool.mu.edu!think.com!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!ugle.unit.no!humpty.edb.tih.no!lumina.edb.tih.no!ketil
  2. From: ketil@edb.tih.no (Ketil Albertsen,TIH)
  3. Newsgroups: comp.protocols.iso.x400
  4. Subject: Re: The "I" field
  5. Message-ID: <1993Jan10.120626.11429W@lumina.edb.tih.no>
  6. Date: 10 Jan 93 12:06:17 GMT
  7. References: <1993Jan8.111416.24490@ugle.unit.no> <726504366snz@mwassocs.demon.co.uk>
  8. Sender: ketil@edb.tih.no (Ketil Albertsen,TIH)
  9. Reply-To: ketil@edb.tih.no
  10. Organization: T I H / T I S I P
  11. Lines: 81
  12. Posting-Front-End: Winix Conference v 92.05.15  1.20 (running under MS-Windows)
  13.  
  14. In article <726504366snz@mwassocs.demon.co.uk>, 
  15. whyman@mwassocs.demon.co.uk (Tony Whyman) writes:
  16.  
  17. >>The recommendation to include the first letter of the G when the G is 
  18. used
  19. >>is silly. Ignore it.
  20. >
  21. >Yes, it is silly, but if you implement the standard ignoring it then a 
  22. >conformance tester may label your implementation as non-comformant. If
  23. >you really think it should be ignored then please send a defect report to 
  24. >the CCITT.
  25.  
  26. I didn't take time to read the entire X.400, so I may have overlooked
  27. something. X.402, 18.3.12 c) identifies "the initials of all his names
  28. but his surname" as an optional piece of information out of the four 
  29. that makes up a personal-name. So it looks as if - in principle - the
  30. initial of the Givenname should be included. 
  31.  
  32. I am honestly surprised. There's a built-in redundancy, unnormalization
  33. or whatever you call it - a built-in source of potential inconsistency.
  34. Further, with this use of I a user interface cannot display a personal-
  35. name by simply printing the G, I and S fields - it must match the
  36. characters in I one by one to the words in G and remove those matching.
  37.  
  38. Also the "one letter per name" does not fit with all national languages
  39. and conventions. Eg. in Norwegian, some names are conventionally
  40. "initialized" using more than one character, such as "Per Christian Bull"
  41. being written "Per Chr. Bull" or "Thorleif Hjeltnes" being "Th. Hjeltnes".
  42. Very often this convention is followed when there is a mute letter, like
  43. the h in Thorleif, or when one sound is written with two characters, like
  44. the k sound written as Ch in Christian. If the inital is written the way
  45. the user has always done it, a strict one-letter-per-name interpretation
  46. would be wrong.
  47.  
  48. Note that "all his names" is not clearly defined. If these are intended
  49. to all be included in G, then the I contains zero bits of information;
  50. I feel that there is something objectionable in maintaining a 0-info
  51. element. If there may be "names" specified nowhere, there is a rule
  52. saying, in effect, "'I' may conatain anything as long as you don't
  53. tell us from which info you derive it - if you tell us, we will catch 
  54. you if you try to cheat us". No, that was not the intention with I.
  55.  
  56. I honestly think that the intention of the I field was to allow people
  57. who don't usually write their name in full to use an (read: some) 
  58. abbreviated form. I think the authors did not intend to prevent people
  59. from writing their name the way they are used to. Quite to the contrary -
  60. I think they explicitly want to honor accepted conventions.
  61.  
  62. Note that both G and I are optional, so you may use either your G+S, I+S 
  63. and G+I+S. And also that a user may have multiple O/R-names - eg. one
  64. in each of these three forms (and the Is don't have to be identical).
  65. I won't believe that a conformance tester could rule an X.400 system 
  66. non-conformant because it didn't detect "cheating" on the I attribute -
  67. I have glanced through X.403 (MHS: Conformance testing) without seeing
  68. anything pointing in that direction. 
  69.  
  70. There is a distinction between Directory name and an O/R address - a 
  71. recipient may have multiple Directory names, eg. with different initials 
  72. formats. Mappingfrom Dir name to O/R address is (as seen from X.400) a 
  73. local matterthat should not influence open systems conformance. When you 
  74. specify to the user interface a set of G, I and S attributes, are they to
  75. be treated as a Dir name subject to directory lookup, or as an O/R 
  76. address? I would definitely prefer the first, Dir name. Then the I
  77. field cannot possibly be defined by X.400 conformance rules - only the
  78. result of the directory lookup. But I can't believe that conformance 
  79. or not of an X.400 system can be a function of data entered by a 
  80. user into a directory system! So, the danger of being caught by a
  81. conformance tester is very close to zero, in my understanding.
  82.  
  83. Another interresting observation is that the X.500 standard attribute
  84. types (X.520) says nothing at all about any I attribute, as far as I
  85. can see. Is it defined somewhere else (in the X.400 series?), or is
  86. I simply not a standard attribute in the directory? (Obviously it can
  87. be stored in X.500 as a non-standard attribute type - about the only
  88. thing you cannot store in X.500 is hamburgers... :-) )
  89.  
  90. Maybe there is a reason to send a defect report to the CCITT about the 
  91. lack of precise specification of the Initials attribute. But I think I
  92. will wait to see the text of the 92 edition to get very upset about it.
  93.  
  94. Ketil Albertsen
  95.