Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jarthur!ucivax!gateway
From: JPALME@qz.qz.se (Jacob Palme QZ)
Newsgroups: comp.protocols.iso.x400
Subject: Order of fields in business card printed O/R-address format
Message-ID: <670472*@MHS>
Date: 28 Mar 91 10:27:43 GMT
Lines: 19
Approved: usenet@ICS.UCI.EDU
X400-Originator: MHSnews.distribution@uninett.no
Content-Identifier: 670472
Autoforwarded: TRUE
X400-Received: by mta pilot.cs.wisc.edu in /PRMD=Internet/ADMD= /C=us/; Relayed;
               Thu, 28 Mar 1991 04:24:06 +0000
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
               Thu, 28 Mar 1991 04:24:00 +0000
X400-Content-Type: P2-1984 (2)
Conversion: Prohibited
X400-MTS-Identifier: [/PRMD=uninett/ADMD= /C=no/;910328112400]

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.