[can.general] The Canadian Domain: Introduction to CA

rayan@ai.toronto.edu.UUCP (11/23/87)

		The Canadian Domain: Introduction to CA
			Updated November 20, 1987

The Canadian domain has been registered with the Network Information
Center (NIC) for the ARPA-Internet. The registration has been organized
by CDNnet with input from representatives of NetNorth, UUCP, and the
Defence Research Establishment. 

Perhaps the most important application of the domain naming scheme
initially is to identify people in order that electronic mail can be
exchanged. Generally, the scheme is intended to be a consistent means
to refer to resources. This note describes the basic structure of the
Canadian domain, and summarizes the information used to arrive at that
structure.

Implications of Registering a Domain

The registration of a Canadian domain with the NIC implies that the
namespace should be structured and managed according to NIC guidelines.
It does not mean that Canada is "joining the ARPANET", and it does not
mean that a host within a registered Canadian subdomain automatically
has the permission to communicate with hosts on the ARPANET, or on any
other network for that matter. These things are separate issues;
registering a domain and deciding on a structure for it only fits us
into the namespace. The issues are closely enough related, however,
that an organization applying for a subdomain under the Canadian domain
will be asked for the names of hosts willing to act as gateways to the
major networks.

Using ARPA guidelines for domain naming does not mean that other ARPA
guidelines and protocols must also be used. This is explicitly
recognized by the designers of the ARPA domain name scheme. This is
just as well, because only a small part of the Canadian community
uses these protocols exclusively.  Neither does it follow that there
must be a widespread shift to the use of ARPA protocols, although
discussing this point is well beyond the scope of this note. Suffice
it to say that standards being put forth by bodies such as ISO and
CCITT are becoming widely implemented and used--this is happening in
Canada now--and it would be unwise to plan a namespace that is
incompatible with them.

Naming and Addressing

In choosing a structure for the Canadian namespace, at least four
naming and addressing systems should be taken into account. The first
is the ARPA-Internet domain name system as described in several
documents including RFCs 882, 883, 920, 921, 973, 974, and 1032. (This
is not intended to be a description of the domain name system.
Interested readers should consult the RFCs.) The domain name space is a
tree, and domains are administrative entities. These two facts together
ensure that there is a decentralized means for managing the namespace,
and especially for assigning unique names. Each domain has an
individual who is responsible for the administration of the names
within the domain. Some of this authority and responsibility may be
delegated to subdomain administrators; this achieves further
decentralization.

The second system is the Originator/Recipient address structure of the
CCITT X.400 recommendations on message handling systems. The O/R
address consists of a list of typed attributes and values. No textual
representation for O/R addresses is specified in the recommendations.
Widely used attributes are country, administration management domain
name, private management domain name, organization name, organizational
units, domain defined attributes, and personal name.

The third system is the Originator/Recipient name structure of the
ISO/CCITT collaborative work on directory standards. These standards
are expected to be approved in 1988, and are called the CCITT X.500 and
ISO 9594 series.  We are concerned mainly with the structure of the
Directory Information Tree.  Here is a simplified description of the
structure:
- Subordinate to the root are organizations and countries.
- Subordinate to a country are organizations and subtrees of
  localities.
- Subordinate to a locality are organizations.
- Subordinate to an organization are organizational persons and a
  subtree of organizational units.
- Subordinate to an organizational unit are organizational persons.
- Subordinate to a locality are residential persons.
In other words, the tree may be described as geographical with
organizations attached at any level, and with persons attached below
organizations and localities.  Note again that this is a simplification
of the actual structure, and of course the entire standard deals with
much more than that structure.

Finally, a way to communicate between X.400 and RFC 822 mail systems is
described in RFC 987 ("Mapping between X.400 and RFC 822"), with an
addendum in RFC 1026. RFC 987 includes a description of mapping
between O/R addresses and RFC 822 addresses. This mapping in general
requires the use of a directory.

In summary, the two main schemes are the ARPA-Internet domain naming
scheme and the CCITT X.400/X.500 naming and addressing scheme. Although
there are differences between them, we should adopt a naming system
that fits into each as naturally as possible. It is likely that a
standard, distributed directory service will be popular outside the
CCITT/ISO world. In particular, it would not be surprising to see work
on gateways to allow access to the directory from the ARPA scheme.
Having some naming compatibility from the outset will be to everyone's
benefit.

Domain Name

The domain CA has been registered. The domain is intended for all of
Canada, although registration of subdomains under CA is voluntary.
Several Canadian subdomains exist under other domains, and there is no
requirement that these other domains (e.g. EDU, COM, MIL, GOV) cannot
be used for new subdomains in Canada. The domain is called CA because
RFC 920 ("Domain Requirements") recommends the use of the two letter
(alpha-2) code for countries according to ISO 3166 ("Codes for the
Representation of Names of Countries"). The same standard is
recommended for use in X.400/X.500, and although each camp allows the
possibility of other names, it makes sense to take the common ground.
(One must always keep in mind that the common ground may be a swamp.)

Domain Structure

In addition to the major standards, the needs of the various
communities should be considered. At present, the major players in the
Canadian networking scene are organizations: universities, government
agencies, companies engaged in research and development, and
progressive companies engaged in other activities. Easy access to
commercial networks may become important, and these are adopting the
CCITT/ISO standards. It is also possible that the individual, not the
organization, will become the major direct force in the future.
However, it is more likely that individuals will fit in under
organizations or will receive services from a service provider such as
a commercial organization. Initially the central administration for CA
will not be able to cope directly with individuals.

The domain should be structured so that the namespace can be
administered easily, and so that names make sense to people. Since a
common unit of administration is the organization and since
organization names are widely used by people when trying to locate
other people, it is reasonable that the namespace should not cut across
organizational boundaries in most cases. 

The structure of the CA domain is a hierarchy. The second-level
subdomains under CA are provincial and territorial abbreviations and
the names of national organizations.  Similarly, the third-level
subdomains are municipality names and provincial organizations.
Fourth-level subdomains are for municipal organizations.  This fits
both major schemes. Since the ARPA scheme does not easily allow for
representing typed information, the two kinds of names are chosen from
the same namespace.  One issue with geographical subdomains is finding
responsible people to manage them.

An organization applying for a registration will be required to request
a geographical subdomain that matches its scope of activity, and to
choose a string that encodes the proper name of the organization in a
widely recognized fashion that will be unique to the requested
geographical subdomain. To simplify the introduction of standard
directory services, the organization string should make sense standing
alone.  The use of nationally recognized abbreviations is recommended,
especially since subdomain names will be widely distributed and will
appear on letterheads and on business cards.

The substructure within an organization is its own business. However,
it is strongly suggested that it be hierarchical, that it fit the
organization's administrative structure, and that the X.500 naming
scheme be considered. 

Current Status

Application forms are available from the registrar and from
participating network administrations. In the future it is possible
that the management of the domain will be taken up by a government
body.

John Demco
CA domain registrar

brad@looking.UUCP (11/23/87)

I understand, with reluctance, why we might have followed the
suggestions in the various proposed standard and gone with "CA" for
a Canadian domain name.  But why on Earth should we use short two letter
postal service names for regional subdomains.

Instead of ON and PQ and AB what's wrong with "Ontario" and "Quebec" and
"Alberta?"   Computers are very good at arranging aliases.  Let the short
two letter names be aliases, defined at whatever level you want to define
them at.

(actually, Ontario and Quebec aren't that hard to type on their own.  Other
names, like British Columbia, Prince Edward Island etc. are more in need
of aliases.   Actually, "BC" and "PEI" are clear well known names for these
regions, so it doesn't matter much here.)

The point is, let the real names be clear and distinct.  Let the computer's
ability to alias take care of the short, typeable names.

-------
I was too busy when this was first discussed.  The postings were too long
and bureaucratic to read.  I regret this now.
-- 
Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473

msb@sq.UUCP (11/25/87)

Here's a late thought on the matter of the domain name.  I "understand,
with reluctance" -- I would say great reluctance -- why we can't have
the normal abbreviation Can, or even the other standard Cdn, and must
have something that looks like California instead.

But CASE is not significant in domain names.  If we spell it "Ca", it
looks a lot LESS like California.  (It does look like calcium, but I don't
think that will confuse anyone.)  The form "ca" would also be acceptable in
this respect, but less so, since it looks like "CA" transformed to lower case.

Can we establish the precedent that the name will, as a matter of style,
normally be spelled as "Ca"?

By the way, to Brad's suggestion:
> Instead of ON and PQ and AB what's wrong with "Ontario" and "Quebec" and
> "Alberta?"   Computers are very good at arranging aliases. ...

I respond that anything that keeps down the length of mail headers these days
is probably good.  Especially when the header is of a mailing list message
sent to numerous people!  Anyway, I'd *rather* see short and well-known
abbreviations used when the context is so standardized.  Just as /bin is
better than /binary, .ON.Ca is better than .Ontario.Canada.

Mark Brader, Toronto			"Don't be silly -- send it to Canada"
utzoo!sq!msb, msb@sq.com			     -- British postal worker

lamy@ai.toronto.edu.UUCP (11/26/87)

In article <1987Nov25.131317.26029@sq.uucp> msb@sq.UUCP (Mark Brader) writes:
>
>By the way, to Brad's suggestion:
>> Instead of ON and PQ and AB what's wrong with "Ontario" and "Quebec" and
>> "Alberta?"   Computers are very good at arranging aliases. ...

As pointed out by Denis Fortin (fortin@zap.uucp) in another forum (his message
will likely get here very late because of problems at musocs), established
usage in both federal and provincial governmental institutions is to use QC as
the abbreviation.

It is indeed a bit silly that PQ is the only abbreviation where the word
"province" appears.  I remember noticing that the abbreviation got out of
style when a political party of the same name got elected.  Pros wanted to
avoid the "P", cons wanted to avoid the subliminal association.

In other words, QC it should be.

Jean-Francois Lamy	               lamy@ai.toronto.edu  lamy@ai.toronto.cdn
AI Group, Dept of Computer Science     uunet!ai.toronto.edu!lamy
University of Toronto                  lamy%ai.toronto.edu@relay.cs.net (arpa)
Toronto, Canada M5S 1A4	               lamy@ai.utoronto, lamy@utorgpu (bitnet)

brad@looking.UUCP (11/26/87)

In article <1987Nov25.131317.26029@sq.uucp> msb@sq.UUCP (Mark Brader) writes:
>I respond that anything that keeps down the length of mail headers these days
>is probably good.  Especially when the header is of a mailing list message
>sent to numerous people!  Anyway, I'd *rather* see short and well-known
>abbreviations used when the context is so standardized.  Just as /bin is
>better than /binary, .ON.Ca is better than .Ontario.Canada.

The point of a domain scheme is that mile long headers go away.  Having your
offical name be Mark_Brader@Toronto.Ontario.Ca isn't very long, but it's
descriptive to anybody, anywhere.   There's no rule that says we can't have
some aliases so that you're at TO.ON.Ca as well, is there?  But the official
names should be real names.

Names are for human beings.  Two letter abbreviations are for COBOL programs.
-- 
Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473

egisin@orchid.UUCP (11/26/87)

In article <1165@looking.UUCP>, brad@looking.UUCP (Brad Templeton) writes:
> The point of a domain scheme is that mile long headers go away.  Having your
> offical name be Mark_Brader@Toronto.Ontario.Ca isn't very long, but it's
> descriptive to anybody, anywhere.   There's no rule that says we can't have
> some aliases so that you're at TO.ON.Ca as well, is there?  But the official
> names should be real names.

Put the full name in the From: comments (see article header), where it belongs.

rayan@ai.toronto.edu.UUCP (11/27/87)

In article <1165@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes:
# There's no rule that says we can't have
# some aliases so that you're at TO.ON.Ca as well, is there?

There are no such rules. The problem in this case is that there is no mechanism
to do this kind of aliasing in a global fashion, or even within a single
network. The only way I can think of to accomplish this, is if *all* mail
goes through a gateway machine whose mailer can do the translation. Since
this is not realistic, aliases for intermediate subdomains (between your
organization and Ca) really cannot exist as far as most of the world is
concerned.

I think much of the reason for using the provincial abbreviations (incidentally,
it appears Quebec will be QC), was that there was no good consistent scheme
using unabbreviated names (or do people really want PrinceEdwardIsland,
NorthWestTerritories, BritishColumbia, etc., like Ontario et al?). The same
argument was the reason for not abbreviating municipality names (no consistent
sensible way of doing it).

rayan

brad@looking.UUCP (11/27/87)

In article <1987Nov26.160644.10193@jarvis.csri.toronto.edu> rayan@ai.toronto.edu (Rayan Zachariassen) writes:
>In article <1165@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes:
>
>The problem in this case is that there is no mechanism
>to do this kind of aliasing in a global fashion, or even within a single
>network. 

Right.  Naming for memorizability and understandability should be the global
function.  Naming for quick typing should be the local function.

Thus the global network names should be the human place names.
(My real beef here starts with "Ca" which is far inferior to "Canada".  Now
if I want international mail I will have to look up cryptic two letter
country codes.  I would gladly pay a few extra keystrokes for understandable
international mail)

>there was no good consistent scheme
>using unabbreviated names (or do people really want PrinceEdwardIsland,
>NorthWestTerritories, BritishColumbia, etc., like Ontario et al?). The same
>argument was the reason for not abbreviating municipality names (no consistent
>sensible way of doing it).
>rayan

The true name should be the most readable name.   "BC" and "PEI" would be
perfectly acceptable official alternate names, although the long names like
British_Columbia should also exist.

The easiest answer to satisfy both drives is to supply both.  For
the provinces it's hardly a major burden.  (Far less typing than this debate)

But the municipalities show up my point.  People from far away won't know
whatever abbreviations local municipalities have.  This place calls itself
"kw", and in T.O. they think of the area as "metro".  Do they know this
in Boise?

Another example is the phone company.  Because of keyboard limitations,
they use "area codes", which you only remember for major places after lots
of use.  For the rest, you have to look on a map.  To call somebody you
don't know requires looking up a code in a book, or calling a directory
service.  A nicely designed naming scheme would make your intuitive first
guess of a person's address the *right* guess.  Can you imagine this for
phone numbers?

-- 
Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473

dan@maccs.UUCP (11/27/87)

In article <1152@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes:
>a Canadian domain name.  But why on Earth should we use short two letter
>postal service names for regional subdomains.
>
>Instead of ON and PQ and AB what's wrong with "Ontario" and "Quebec" and
>"Alberta?"   Computers are very good at arranging aliases.  Let the short
>two letter names be aliases, defined at whatever level you want to define
>them at.

Yeah sure...  so my site name will be

dan@css.mcmaster.hamilton.ontario.ca

This would do wonders for my business card. In fact the bang style addressing
is shorter than this. The point here is that with use these abbreviations
will become *well known* and there will be no need to specify longer *more*
specific regional names. In fact I don't even like the fact that municipality
names are full length or the fact that the domains are regional at all. But 
since we are a *well known* educational institution I only have to specify
".mcmaster.ca" and this makes me happy again.

At first I was more than a little frustrated at the seemingly lack of movement
in regards to the Canadian domain scene but I see that a lot of people have
contributed time and energy towards this cause and I wish to thank them for
the efforts they made to bring this about. Since I did not participate in any
great way, except answer a questionaire, I have no place *now* in criticizing
the efforts of those that were involved.

-- 
       A.I. - is a three toed sloth!        | ...!uunet!mnetor!maccs!dan
-- Official scrabble players dictionary --  | dan@mcmaster.BITNET

sjl@myrias.UUCP (11/28/87)

I don't understand this mania with two letter abbreviations. It may be that
the two letter abbreviations for the provinces and territories that were
posted do exist in some official Canada Post memo, but for as long as I can
remember the accepted abbreviations for the names of the provinces and
territories have been:

British Columbia	BC
Alberta			Alta
Saskatchewan		Sask
Manitoba		Man
Ontario			Ont
Quebec			Que or PQ (to distinguish it from Quebec City)
New Brunswick		NB
Nova Scotia		NS
Prince Edward Island	PEI
Newfoundland		Nfld
Yukon			Yukon	  (I have also seen YT)
North West Territories	NWT

I claim that all of these abbreviations are familiar and sufficiently short.
As has been pointed out, an address created from nested domains just does
not get as long as the UUCP path names that many of us are used to seeing.
People have been perfectly happy to write these names out longhand on letters
for years, I can't imagine any reason why they are suddenly too hard for
anyone's tender fingers to type.

Stuart Lomas
Myrias Research Corporation
Edmonton, Alta
{ihnp4,mnetor,ubc-vision}!alberta!myrias!sjl

louis@auvax.UUCP (11/29/87)

In article <539@myrias.UUCP>, sjl@myrias.UUCP (Stuart Lomas) writes:
> I don't understand this mania with two letter abbreviations. It may be that
> the two letter abbreviations for the provinces and territories that were
> 
> British Columbia	BC
> Alberta			Alta

Tell me that Alta is better than AB.  I lived for a while in Palo Alto,
while at Stanford, and could appreciate Alto, but Alta, is confusing,
and _not_ as descrptive as AB.  Then, I may be thinking of the famous
ski rseort in Utah by the name of Alta.  Really, it is famous.

Hoch soll es leben, einmal prosst.
-- 

Louis Schmittroth		           My employer has no opinions.
Computer Science
Athabasca University   ...{ubc-vision, ihnp4}!alberta!auvax!louis

daveb@geac.UUCP (11/30/87)

>In article <1165@looking.UUCP>, brad@looking.UUCP (Brad Templeton) writes:
>> The point of a domain scheme is that mile long headers go away.  Having your
>> offical name be Mark_Brader@Toronto.Ontario.Ca isn't very long, but it's
>> descriptive to anybody, anywhere.  

In article <11863@orchid.waterloo.edu> egisin@orchid.UUCP writes:
>Put the full name in the From: comments (see article header), where it belongs.

  The "From" comment indicates a substantial misunderstanding of the
RFCs on mail: that comment fiedl was to put the real pre-domain form
of your name into if you had a brain-damaged mailer that wouldn't
take "David R. Brown of TSDC" @ Hi-Multics, but demanded the
arpanaut version of the minimalist address: DRBROWN.TSDC@HI-MULTICS.

[Fer gunnis sake, if you're going to make snarky comments, get your
facts straight: even pre-domain mail was aimed at being able to say
the equivalent of Mark_Brader@Toronto.Ontario.Ca]

--dave (see below) c-b
-- 
 David Collier-Brown.                 {mnetor|yetti|utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

rbutterworth@orchid.UUCP (12/03/87)

In article <430@auvax.UUCP>, louis@auvax.UUCP (Louis Schmittroth) writes:
> In article <539@myrias.UUCP>, sjl@myrias.UUCP (Stuart Lomas) writes:
> > I don't understand this mania with two letter abbreviations.
> > British Columbia    BC
> > Alberta       		Alta
> Tell me that Alta is better than AB.

OK, "Alta" is better than AB.

Now let's see you tell us that "MA" is better than "Man" or "Manitoba".
Remember that "MA" is already used for either "Maine", "Massachusetts",
or "Maryland", or maybe "Minnesota" or "Montana", I can never remember
which.

egisin@orchid.UUCP (12/07/87)

In article <1903@geac.UUCP>, daveb@geac.UUCP writes:
>   The "From" comment indicates a substantial misunderstanding of the
> RFCs on mail: that comment fiedl was to put the real pre-domain form
> of your name into if you had a brain-damaged mailer that wouldn't
> take "David R. Brown of TSDC" @ Hi-Multics, but demanded the
> arpanaut version of the minimalist address: DRBROWN.TSDC@HI-MULTICS.

Maybe we are talking about different things, but I don't see anything in
rfc 822 that suggests what does and does not belong in comments.
Here's any example from rfc 822 that does exactly what I suggested in
my original article: it expands an abbreviation in the domain.

	Childs@WGBH.Boston, Galloping Gourmet@
	ANT.Down-Under (Australian National Television)
[yes, I noticed the local part is illegal]