JPALME@qz.qz.se (Jacob Palme QZ) (03/28/91)
A couple of weeks ago I got the question of the standards meeting in february on X.400/MOTIS development really intends to list the OU-s starting with the largest unit, but list all other attributes starting with the smallest unit, since this could be confusing to humans using the recommendation for "representation of o/r addresses for human usage". I have now checked the output document from the meeting, and, unfortunately, yes, the case is as described above. For example, a printed O/R-address might look like this: G=John;S=Smith;O=XYZ University;OU1=Computer division;OU2=Software unit;A=" ",C=SE Note however that the OU-s are numbered, OU1, OU2 etc. So the order in which they are given does not really convey any information, the subfields can be scrambled in any order without loss of information.
JPALME@qz.qz.se (Jacob Palme QZ) (03/29/91)
> From: Erik Skovgaard <eskovgaa@cue.bc.ca> > I am puzzled - when keywords are used, why is position specified? Well this is a standard for printing the fields on business cards, postal letter heads etc. And it is assumed that most user interfaces will use some kind of form-fill-in procedure. And of course it will then be easier for a human to copy the values of the fields from the business card into the form on the screen, if the order of the different fields is the same. Another possible user interface would of course be if the user copies the whole "human readable string" directly into his computer. The human factors study did however indicate, that this is a less efficient and more error-prone method for inputting an OR-address than a form-fill-in user interface with separate fields for each OR-address attribute.
eskovgaa@cue.bc.ca (Erik Skovgaard) (03/29/91)
I think that is unncessecarely ridgid. Most user interfaces that I know
of can handle any order - at least the ones that use keywords.
I am concerned about the ridgid ordering for another reason: compatability
with the Directory Name. The Directory name would look quite similar,
but i would find it most natural to specify that using the country name
first.
The keyword approach I can fully agree with. It is more intuitive (or at
least as close to that as an X.400 O/R-anme can be) and quite easy to
use. I just do not think you need to specify the ordering.
....Erik.JPALME@qz.qz.se (Jacob Palme QZ) (03/31/91)
If the user interface requires keywords from the user, then it can and should of course accept the different fields of the O/R-name in arbritary order. If however, the user interface displays a form on the user screen, with different fields, which the user can fill in, then these fields on the screen should preferably be in the same order as the fields on the business card. What you say about the directory names is important. Of course, ISO/CCITT should make a standard for writing OR-adresses on business cards which is compatbile with the format for writing directory names on the same card. I hope the people who make the standard will take this into consideration.
Dan@dna.lth.se (Dan Oscarsson) (04/01/91)
In article <670472*JPALME@QZ.qz.se> JPALME@qz.qz.se (Jacob Palme QZ) writes: >A couple of weeks ago I got the question of the standards >meeting in february on X.400/MOTIS development really >intends to list the OU-s starting with the largest unit, >but list all other attributes starting with the smallest >unit, since this could be confusing to humans using the >recommendation for "representation of o/r addresses for >human usage". > >I have now checked the output document from the meeting, >and, unfortunately, yes, the case is as described above. > >For example, a printed O/R-address might look like this: >G=John;S=Smith;O=XYZ University;OU1=Computer >division;OU2=Software unit;A=" ",C=SE > Do X.400 really think a normal user would like to use such a complex address structure like the O/R-address? All these irretating tags on every part of the address, why do you need them? The domain address used by the Internet is much simpler. Dan -- Dan Oscarsson Department of Computer Science Lund Institute of Technology e-mail: Dan.Oscarsson@dna.lth.se Box 118 S-221 00 Lund, Sweden
NTIN36@gec-b.rutherford.ac.UK (Jim Craigie) (04/05/91)
---- Start of forwarded message.
Via: [+JANET.00000511168030.UCL-CS.FT]; Tue, 2 Apr 91 09:34 BST
(V39 at UK.AC.RUTHERFORD.GEC-B)
Date: Tue, 2 Apr 91 9:27:32 BST
From: Nigel Bevan <nbevan@uk.ac.ucl.cs.ess>
To: jpalme@se.qz.qz
cc: craigie@uk.ac.rutherford, nbevan@uk.ac.ucl.cs.ess
Subject: Order of fields in business card printed O/R-address format
The standards group gave long and exhausive consideration to different
possible orders for the representation of fields. One point was clear -
most ordinary users expect (and find it convenient for) an address to start
with the person's name. For example the Retix X.400 interface on the PC
uses a form-fill layout which starts with the person's name. (Which,
incidentally, is a vast improvement on earlier Retix interfaces!) The
standards group concluded that you need to associate a person's name with
organisational information, so that after G and S you need O or OU
information.
The reason for deciding to put the OUs in ascending order after the O, is
that:
- OUs need to be numbered top-down so that the optional more detailed OUs
which can be omitted have higher numbers, and then
- G, S, O, OU1, OU2, OU3, OU4 seems a better order for the user than
G, S, OU4, OU3, OU2, OU1, O, as for the user the G, S, O combination will in
most cases itself be unique and the OUs are then given in ascending numerical
order.
(Analogous conventions can be found in postal addresses.)
The reasons for recommending an order at all are:
- to increase consistency in the representation of addresses, so that they
are easier to recognise
- to simplify the task for the user, particularly when copying from one
representation to another (eg one-line labelled format to a form-fill user
interface)
Note that the standard requires the syntax to be used, but only recommends that
the order is followed.
Another point about the standard representation is that it prohibits use of
A=" ". If no ADMD is specified it should be omitted from the address. User
interfaces are required to interpret the omission of the ADMD as meaning
that the value " " should be used (provided this convention is valid for the
country specified).
---- End of forwarded message.Dan@dna.lth.se (Dan Oscarsson) (04/06/91)
In article <05APR199101:21:59NTIN36@UK.AC.RUTHERFORD.GEC-B> Nigel Bevan <nbevan@ess.cs.ucl.ac.UK> writes: > >The standards group gave long and exhausive consideration to different >possible orders for the representation of fields. One point was clear - >most ordinary users expect (and find it convenient for) an address to start >with the person's name. For example the Retix X.400 interface on the PC >uses a form-fill layout which starts with the person's name. (Which, >incidentally, is a vast improvement on earlier Retix interfaces!) The >standards group concluded that you need to associate a person's name with >organisational information, so that after G and S you need O or OU >information. > >- G, S, O, OU1, OU2, OU3, OU4 seems a better order for the user than >G, S, OU4, OU3, OU2, OU1, O, as for the user the G, S, O combination will in >most cases itself be unique and the OUs are then given in ascending numerical >order. > >(Analogous conventions can be found in postal addresses.) > But a postal address looks like: Dan Oscarsson Dept. of Computer science Lund Institute of Technology Lund Sweden That is: N, OU, O, T, C Why not define that a mail address should look like: name, [,subunit]..., unit, country My address for email could then be: Dan Oscarsson,DNA,LTH,se No need for G= S= (why separate the parts of a name?) or other prefixes, no need for ugly slashes. This type of address could easily be looked up in a directory like X.500. Dan -- Dan Oscarsson Department of Computer Science Lund Institute of Technology e-mail: Dan.Oscarsson@dna.lth.se Box 118 S-221 00 Lund, Sweden
nbevan@ESS.Cs.Ucl.AC.UK (Nigel Bevan) (04/10/91)
If only it were so easy ... one of the frustrations of O/R addresses is that
since there are few restrictions on the characters permitted in fields, many
apparently simple formats are syntactically ambiguous. Which is the OU and
which the O in Dan Oscarsson,DNA,LTH,se? (and what about the PRMD and ADMD?)
Another possibility would be an address represented in a format comparable to
internet:
John.Smith@DP Dept.Bank of Britain.BBANK.Gold 400.GB
Unfortunately "@" is not an at sign on all keyboards (or screens!), "." can
appear in fields, there are ambiguities in the representation of names and
initials, and it is awkward to represent missing fields in this syntax!
(Incidentally, I am editor of the standard for the representation of O/R
addresses, and I am not on the mhsnews list.)nbevan@ESS.Cs.Ucl.AC.UK (Nigel Bevan) (04/10/91)
I agree with Christian that it would be nice to have plan for the type of functionality he suggests, but if we forget the idea of the representation of O/R addresses in the mean time, I suspect it could be a long wait until we have standards for "user friendly directories"! I agree that since the standard does not number OUs the order should not be significant. But the standard says it is, and I assume almost all implementations treat it as significant. Another case for a standard for fuzzy matching! Another trivial bit of functionality which would avoid numerous errors, would be if one or more spaces in a field were treated as NO spaces, rather than as one space at present, ie spaces should be ignored. Users are not very good at noticing significant spaces in proprietry names. (To be sure to receive mail, select an ADMD that does not have a space in their name!)