ADMD=Internet etc.

Alf Hansen <Alf.Hansen@delab.sintef.no> Wed, 05 August 1992 11:24 UTC

Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id ab02104; 5 Aug 92 7:24 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02100; 5 Aug 92 7:24 EDT
Received: from mhs-relay.cs.wisc.edu by NRI.Reston.VA.US id aa06162; 5 Aug 92 7:24 EDT
X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Wed, 5 Aug 1992 05:21:25 +0000
Date: Wed, 05 Aug 1992 05:21:25 +0000
X400-Originator: cargille@cs.wisc.edu
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/; mhs-relay..104:05.07.92.10.21.25]
Priority: Non-Urgent
DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Wed, 5 Aug 1992 05:21:25 +0000;
From: Alf Hansen <Alf.Hansen@delab.sintef.no>
Message-ID: <2739*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/C=no/@MHS>
To: /S=ietf-osi-x400ops/OU=cs/O=UW-Madison/PRMD=xnren/C=us/ </S=ietf-osi-x400ops/OU=cs/O=UW-Madison/PRMD=xnren/C=us/@cs.wisc.edu>
Subject: ADMD=Internet etc.

Hi all,

I like this lively discussion. My few remarks are the following:

First of all I think it is correct to use this list (ietf-osi-x400ops) for this
discussion because, even if this is a U.S. matter, the process now taking place
in the U.S. is of great interest for other countries as well. Perhaps we can all
learn somthing from it.

Stef asks:

> I think it is unfortunate if we have really chosen to use
> PRMD=INTERNET.  When did we do that.  I thought we chose to use
> PRMD=XNREN to carefully avoid getting into the problem you cite.
> 
> When and where did we start using PRMD=INTERNET, and was it an IETF
> decsion?  

This was debated at the so called IXOM meeting in Madison, WI, Nov. 20 1990, and
later confirmed as the so called "St. Louis-decision" at the St. Louis IETF.
This is from thi IXOM minutes:

--------------
6.  Alf Hansen led a discussion on representing Internet RFC822
addresses in X.400.  The two common strategies are using the
RFC-822 domain defined attribute or mapping components of an RFC822
address into standard elements of an O/R address.

The problem was divided into two parts:  first, identifying the RFC822
community or a specific RFC987 gateway, and second, enclosing the
RFC822 address.  Attendees agreed that a solution which forced routing
to a specific gateway was undesirable.  This will be a major topic of
discussion at the next meeting.

In general, the high components of an O/R Address are used to identify
a gateway or community.  For example,

    Identifies Gateway:    /C=uk/PRMD=ac.uk/O=relay/
    Identifies Community:  /C=us/PRMD=RFC-822/

In general, lower components of the O/R Address are used to identify
the RFC-822 user.  The RFC-822 address can either be "exploded" into
O/R Address fields, or "encoded" intact inside a domain-defined
attribute field.  For example,

    Exploded address:  /O=edu/OU=wisc/OU=cs/S=user/
    Encoded address:   /DD.RFC822="user(a)cs.wisc.edu"/

-------------


and this is from the St. Louis minutes (March 12-13 1991):


--------------
7. Specification of RFC822 addresses in the X.400 world

   It was agreed that RFC822 addresses should be expressed using X.400
   domain defined attributes.  Furthermore, a special PRMD named "Internet"
   will be defined to facilitate the specification of RFC822 addresses.
   For example, an X.400 user will address an RFC822 recipient by
   constructing an X.400 address such as:

     /c=us/admd= /prmd=Internet/dd.RFC-822=user(a)some.place.edu/

   Participating MTA's will be configured to recognize
   "/c=us/admd= /prmd=Internet/" as a special case.  The presence of
   this address will cause a message to be routed to a regional RFC987
   gateway.  In effect, this special PRMD identifies a community of
   gateways to RFC822 recipients.  This strategy is user friendly in that all
   users everywhere need only remember this one gateway address, and it is
   efficient in that it avoids having to establish a single, common gateway
   which would tend to become a bottleneck and single point of failure.

-------------


Later discussions have resulted in the following text in the so called
"operational requirements" document

    draft-ietf-x400ops-mgtdomains-01.txt   :


-------------

3.3.1.  Specification of RFC-822  addresses  seen  from  the
X.400 world

Two scenarios are described:

    A. The RFC-822 end-user belongs to an organization with no defined X.400
       standard attribute address space.
    B. The RFC-822 end-user belongs to an organization with a defined X.400
       standard attribute address space.


Organizations belong to scenario B if their X.400  addresses
are registered according to the requirements in section 3.1.

3.3.1.1.  An  organization  with  a  defined  X.400  address
space

An RFC-822 address for an Internet  mail  user  in  such  an
organization  shall  look  exactly as a normal X.400 address
for X.400 users in the same organization. Example:

University of Wisconsin-Madison is  registered  under  C=US;
ADMD=  ;  PRMD=XNREN;  with  O=UW-Madison and they are using
OU=cs to address end-users in the CS-department. The RFC-822
address  for  Internet mail users in the same department is:
user@cs.wisc.edu.

An X.400 user in  the  GO-MHS  Community  will  address  the
Internet  mail  user  at  the  CS-department  with the X.400
address:

    C=US; ADMD= ; PRMD=xnren; O=UW-Madison; OU=cs; S=user;


This is the same address space as is  used  for  X.400  end-
users in the same department.

3.3.1.2.  An organization  with  no  defined  X.400  address
space

RFC-822 addresses shall  be  expressed  using  X.400  domain
defined  attributes.   The mechanism used to define the RFC-
822 recipient will vary on a per-country basis.

For example, in the US, a special PRMD named  "Internet"  is
defined   to   facilitate   the   specification  of  RFC-822
addresses. A X.400 user can address an RFC-822 recipient  in
the U.S. by constructing an X.400 address such as:

    C=us; ADMD= ; PRMD=Internet; DD.RFC-822=user(a)some.place.edu;


The first part of this address:

    C=us; ADMD= ; PRMD=Internet;


denotes the U.S. portion of the Internet community and not a
specific "gateway". The 2nd part:

    DD.RFC-822=user(a)some.place.edu


is the RFC-822 address of the Internet mail user after  sub-
stitution of non-printable characters according to RFC-1148.
The RFC-822 address is placed in  an  X.400  Domain  Defined
Attribute of type RFC-822 (DD.RFC-822).

Each country is free to choose its own  method  of  defining
the  RFC-822 community.  For example in Italy, an X.400 user
would refer to an RFC-822 user as:

    C=IT; ADMD=MASTER400; DD.RFC-822=user(a)some.place.it


In the UK, an X.400 user would refer to an RFC-822 user as:

    C=GB; ADMD= ; PRMD=UK.AC; O=MHS-relay; DD.RFC-822=user(a)some.place.uk

--------------------


Based on the discussion and conclusions from Boston IETF, I am tasked to update
this text such that when U.S. examples are used, C=US; ADMD= ; PRMD=Internet;
should be replaced by

    C=US; ADMD=Internet;

Stefs Internet draft will document the basic rules for how the U.S. portion 
of the Internet wants the RFC-822 addresses to look like seen from the 
X.400 world.

Internet drafts from other countries will document how this is done
in other countries. Hopefully the result will be that most countries do this
in the same way, or at least there will be blocks of countries with
similar solutions.

When all these Internet drafts have been approved, we will have a nice
collection of documents describing how the RFC-822 world is represented seen
from the X.400 world.

This is not so complicated, is it?

Best regards,
Alf H.