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.
- ADMD=Internet etc. Alf Hansen
- Re: ADMD=Internet etc. (Tony Genovese)
- Re: ADMD=Internet etc. Russ Wright
- Re: ADMD=Internet etc. Alf Hansen
- Reply to ADMD=Internet etc. Kevin E. Jordan
- Reply to ADMD=Internet etc. Harald Tveit Alvestrand
- Reply to Reply to ADMD=Internet etc. Kevin E. Jordan
- ADMD=PRMD=Internet is not a big problem (was: Re:… Einar Stefferud