Re: Multi-national company listing issues

[Tony Bartoletti <azb@xxxxxxxx>]

All,

Just an observation:)  I get a strange sense of Deja Vu here.

As Paul Koning remarked, in the US at least, the designation
"C=US" means "The party in question paid ANSI the required fee,
so ANSI registered the entry under 'US'" (loosely paraphrased)."

So, if you want more specifics, consult ANSI's "RPS" (Registration
Practices Statement.)  OK, I'm making that part up, its a take-off
on "CPS", for those who don't get it otherwise :)

___tony___


At 05:27 PM 8/30/99 -0600, Bob Jueneman wrote:
>Ed,
>
>I used a conventional X.400 representational shorthand for 
>the attribute called "country"  I would always assume that 
>localization of any display code would translate that 
>appropriately, if that was felt to be necessary.
>
>Bob
>
>
>
>>>> Ed Gerck <egerck@nma.com> 08/27/99 11:01AM >>>
> Bob Jueneman <BJUENEMAN@novell.com> wrote:
>
>> For example, is "C=" the country where the parent is located,
>> where the subsidiary is located, where the tiny field office is
>> located, where they are incorporated (think of a ship with
>> Liberian registry), etc., etc.?
>>
>> In the case of an individual user, is the country where he was
>> born (or adopted)? Where he is currently a citizen (what about
>> dual citizenship, stateless persons, and nomads)?  Where he
>> maintains a residence (or maybe a domicile)?  Where he works (I
>> assume some people work in one country and sleep in another,
>> every day)?
>
>Bob:
>
>What is the meaning of "C=string"?
>
>There are two ways to solve this. One, is to proceed with the hierarchical
>type structure as a taxonomy and provide all the possible ramifications --
>clearly, with very little chance of satisfying even just the majority of cases.
>The other way is to renounce the concept (wrong, anyway) of "denotational
>syntax", treat the hierarchical structure as an an ontology and consider all
>qualifiers from the syntactic point of view, as "names".  With this approach,
>the meaning of "C=string" is now clear:
>
>"C" and "string" are specified, and "C" stands in equivalence with "string"
>
>Here, "C" is a name -- a quite arbitrary designation that is simply formally
>defined and may (or not) have a mnemonic purpose or be expressed in
>a human language.  In other words, "C" is just a pointer, a handle in an
>hierarchical ontology (not in a taxonomy).  OTOH, "string" may be either
>a name or a record as usual, where records refer mainly to physical
>quantities (e.g., geographical data, network addresses, port numbers,
>service designations, company names, etc.) designated in a materially
>pre-defined form.  The  map and query methods of a database can then
>relate names to records in a variety of relationships according to local
>need, such as one-to-one, many-to-one, one-to-many or many-to-many.
>The database can also follow a variety of models such as hierarchical,
>network, relational, distributed hierarchical, etc.
>
>What is required to do this? Nothing, just renounce the taxonomy and
>employ the same hierarchical structure already in place in X.500 or
>LDAP or whatever is being used.  Even the same relational tables
>if a relational database model is followed.
>
>But, where is the meaning of "C" denoted?  Not, in "C" itself but in the
>trusted context -- where it is anyway defined.  For example, "C" is
>meaningless in German as an abbreviation for Country -- it is the trusted
>context which says so (but, with all the ambiguities you point out and
>which are basically irresolvable).
>
>The integration of different trusted contexts becomes then a problem,
>but one which I believe is being increasingly solved in database theory
>-- for example, with meta-directory approaches.
>
>Of course, denotational syntax also "works" one may say -- but only in a
>parochial environment where the trusted context is implicitly known.  Since
>we are past this stage in the Internet, the fact that syntax and semantics
>are independent variables can no longer be ignored and must be either
>properly handled or threatens to overwhelm.
>
>Cheers,
>
>Ed Gerck
>
>
>
>