Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (05/17/91)
============================================================================
T H E 4 0 0
Internet X.400 Pilot Project Newsletter No 2
May 17 1991
Queries to:
C=us; ADMD= ; PRMD=xnren; O=UW-Madison; OU=cs; S=x400-project-team
x400-project-team@pilot.cs.wisc.edu
Phone: +1 608 262 5084
Fax: +1 608 262 9777
Computer Sciences Department, University of Wisconsin-Madison,
1210 West Dayton Street, Madison, Wisconsin 53706, USA.
============================================================================
THIS IS OUR SECOND NEWSLETTER.
------------------------------
This Newsletter will on a regular basis inform you about the recent
developments in our project. The information is intended for
- Organizations already participating in the experimental Internet
X.400 service.
- Organizations that may be interested in joining either as an MTA
under PRMD=XNREN or as a subscriber to other PRMDs in the
Internet.
- Any other interested parties.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The project is maintaining a file store of documents.
-----------------------------------------------------
Internet X.400 documents are available by anonymous FTP from a file store
maintained by the Internet X.400 Pilot Project in Wisconsin. Login with
the username "anonymous" and password "guest" on the machine
mhs-relay.cs.wisc.edu (128.105.8.53). After logging in, position yourself
to the correct directory:
type "cd pub" to find this catalog
type "cd pub/argo" to find information about the ARGO X.400
implementation.
type "cd pub/doc" to find the documents describing the current
operational documentation of the pilot Internet X.400
service.
type "cd pub/gen" to find general information resulting from the
Internet X.400 project.
type "cd pub/ietf" to find documents related to the IETF X.400
Operations WG.
Type "ls" to get a list of documents.
If you are a newcomer, the documents marked as 1 2 3 4 contain background
material and should be read first. The following files are available:
Last modified Filename Explanation
------------------------------------------------------------------------------
pub/
May 17 1991 catalog.txt This catalog file.
pub/argo/
*** Contains information about the ARGO X.400 implementation.
Apr 9 1991 argo-info.txt General information.
Apr 9 1991 sysadmin.n System adm. aspects.
Apr 9 1991 sysadmin.out
Apr 9 1991 users.n User facilities.
Apr 9 1991 users.out
pub/doc/
*** Contains documents and information about documents describing the pilot
*** Internet X.400 service. Intended for service managers.
May 1 1991 country-us-prmds List of Internet PRMDs.
May 15 1991 doc-info.txt Info about the documents.
May 1 1991 format-documents.txt Formal format description.
May 16 1991 i-wep Description of I-WEPs.
Apr 18 1991 mta-us Description of MTAs.
Apr 17 1991 org-us Description of Organizations.
Apr 2 1991 rfc987-mapping1 Current address mapping tables.
Apr 2 1991 rfc987-mapping2
pub/gen/
*** General information resulting from the Internet X.400 project.
Feb 13 1991 88-to-84-downgrading-kille.txt
Feb 13 1991 dns-987.ps Draft RFC for use of DNS to
Feb 13 1991 dns-987.txt manage RFC 987 mapping info.
Jan 25 1991 4 how-to-join.txt Info on how to join the service
Feb 13 1991 ixom-minutes-nov-28-90.txt Initial meeting in Madison.
Feb 13 1991 mhs-md-1st-meeting-rep.txt MHS-MD is a subgroup of the
Feb 13 1991 mhs-md-1st-meeting-slides.txt U.S. CCITT study group D.
Apr 9 1991 mhs-md-2nd-meeting-rep.txt
Jan 14 1991 na-form.txt XNREN X.400 registration form.
Jan 14 1991 na-statutes.txt Statutes XNREN Naming Authority
Jan 14 1991 1 newsletter-1.txt Newsletter, 1st issue.
May 17 1991 2 newsletter-2.txt Newsletter, 2nd issue.
Jan 14 1991 3 prospectives.txt Prospectives for X.400 organiz.
pub/ietf/
*** Contains documents related to the IETF X.400 Operations WG.
Feb 18 1991 agenda-st-louis-march-12-13-91.txt
Apr 9 1991 cdc-x500-usage.txt CDC product's X.500 usage.
Feb 13 1991 charter.txt IETF X.400 OPS WG charter.
May 13 1991 i-wep-def.txt Draft definition of I-WEP.
Apr 5 1991 minutes-st-louis-march-12-13-91.txt
Apr 9 1991 rfc-987-multimedia-ext.txt Contribution from CDC.
Feb 13 1991 status-cdc.txt Input to St. Louis meeting.
Feb 13 1991 status-xnren.txt Input to St. Louis meeting.
------------------------------------------------------------------------------
Documents are located at:
o CS-Department, UW-Madison
Address: mhs-relay.cs.wisc.edu (128.105.8.53)
For questions, please mail to
c=us; admd= ; prmd=xnren; o=UW-Madison; ou=cs; pn=postmaster
postmaster@pilot.cs.wisc.edu
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
What has happened since November 90?
------------------------------------
IETF:
The IETF X.400 Operations WG meeting in St. Louis, March 12-13 1991,
showed that there is a great interest in X.400 operations in the Internet
community. Some major draft decisions were made in St. Louis:
1) The WG agreed on an X.400/RFC-822 address mapping scheme for the U.S.
Internet community (will be described later in this Newsletter).
2) A minimum solution for X.400 routing, using a structure of I-WEPs,
was adopted.
3) Documents in the Internet X.400 Documentation will be used as a
mechanism to describe and ensure end-user X.400 connectivity over
different underlaying network protocol suites (RFC-1006/TCP/IP -
TP-0/X.25 - TP-4/CLNP)
4) An outline of a new RFC: "Requirements for Internet PRMDs," was
drafted.
The project team will produce the draft RFC described in 4) to be reviewed
at the next IETF in Atlanta (July 29 - August 2 1991).
OPERATIONAL STATUS:
The draft decisions made on address mapping, routing and documentation
are to be implemented by the pilot operational Internet X.400 services now
comprising 4 operational PRMDs: ARC, CDC, Hughes and XNREN.
The number of real X.400 users is still very low. However with the new
operational PRMDs, the number is growing.
The following organizations are operational and interconnected as X.400
systems. Addressing examples are given in order to show what the X.400
addresses look like. The X.400 addresses are presented both in X.400
Standard Attribute (SA) form and in RFC 822 form.
Organizations,
PRMD XNREN: X.400 address in SA form and RFC 822 form
------------------------------------------------------------------------
University of Wisconsin-Madison
Madison, WI
C=us; ADMD= ; PRMD=xnren; O=uw-madison; OU=cs; S=User
User@pilot.cs.wisc.edu
National Science Foundation
Washington, D.C.
C=us; ADMD= ; PRMD=xnren; O=nsf; PN=User
User@pilot.nsf.gov
Rice University
Houston, TX
C=us; ADMD= ; PRMD=xnren; O=rice-univ; PN=User
User@exp.rice.edu
Mitre Corporation
McLean, VA
C=us; ADMD= ; PRMD=xnren; O=mitre; OU=ieg; PN=User
User@pilot.ie.org
University of Pennsylvania
Philadelphia, PA
C=us; ADMD= ; PRMD=xnren; O=upenn; OU=cis; PN=User
User@pilot.upenn.edu
Organizations,
PRMD Hughes: X.400 address in SA form and RFC 822 form
------------------------------------------------------------------------
Hughes Aircraft Company,
Space & Communications Group
Los Angeles, CA
C=us; ADMD=MCI; PRMD=Hughes; O=SCG; OU=whitney; S=User
User@whitney.hac.com
Organizations,
PRMD ARC: X.400 address in SA form and RFC 822 form
------------------------------------------------------------------------
NASA-Ames Research Center
CA
C=us; ADMD=telemail; PRMD=arc; O=nasa; OU=argo; PN=User
User@pilot.arc.nasa.gov
Organizations,
PRMD CDC: X.400 address in SA form and RFC 822 form
------------------------------------------------------------------------
Control Data Corporation
Arden Hills, MN
C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=User
User@cpg.cdc.com
These organizations can communicate with X.400 users in the R&D MHS
Service in the following countries:
Austria, Australia, Belgium, Canada, Denmark, Germany, Finland, France,
Iceland, Ireland, Italy, The Netherlands, Norway, Portugal, Spain, Sweden,
Switzerland, United Kingdom, and Yugoslavia.
The project is operating an RFC 987 gateway (PP) between the U.S. Internet
mail service and the international R&D MHS Service (X.400). This gateway
is also the experimental U.S. WEP (WEP = Well known Entry Point) in the
COSINE MHS Service in Europe, and it is directly connected to other WEPs
in Canada, Finland, France, Norway, Spain, Switzerland and United Kingdom.
X.400 traffic to the other countries in the COSINE MHS Service, is routed
via the Norwegian WEP operated by the UNINETT project.
France, Norway, Spain and Switzerland are routing some of their X.400
initiated traffic destined to the U.S. Internet mail domains, via our
gateway as an experiment. This means that messages initiated in X.400
can be kept in the X.400 "world" all the way to the U.S. and gatewayed
here, if necessary. Due to these routing experiments the monthly traffic
through our WEP has increased considerably.
TECHNICAL ASSISTANCE:
The project is distributing the ARGO X.400 implementation to
non-commercial organizations, and we are also offering assistance to
organizations who are starting to use the PP X.400/RFC-987 gateway system
from UCL, London. The assistance we offer is limited to operational
issues, initial PP configuration, address mapping tables, etc. E-mail us
if you would like such assistance. General software support should be
obtained from the pp-support team in London.
EXTERNAL PRESENTATIONS:
The project was presented at the 2nd Joint European Networking Conference
in Blois, France, May 13 - 16 1991. "X.400 in the Internet" will be
presented at the INET '91 Conference in Copenhagen, Denmark, June 17 - 20
1991.
VALUE ADDED SERVICES:
The project team is developing a FAX gateway service between X.400 and
FAX. Status so far is that a text file can be sent to a given fax number.
More work has to be done to develop this into a useful service allowing
end-users to use their X.400 User Agent to send a text message to a fax-
subscriber in the U.S. It is a goal to negotiate agreements with other
countries such that X.400 users in the U.S. also can send international
fax using similar fax gateways in other countries.
This service, when developed, will be made available for all X.400
users in the Internet X.400 service, and also on a bilateral basis to
X.400 users in other countries.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* * * Topic of today: * * *
The "St. Louis decision" on address mapping.
--------------------------------------------
The draft decision in St. Louis is valid for the U.S. Internet, and can
also be viewed as a recommendation for communities outside the U.S.
The address mapping issue can be split into two parts:
1) Specification of RFC-822 addresses seen from the X.400 world.
2) Specification of X.400 addresses seen from the RFC-822 world.
1) Specification of RFC-822 addresses seen from the X.400 world.
The following is from the St. Louis minutes:
" 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 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."
2) Specification of X.400 addresses seen from the RFC-822 world.
The following is also from the same minutes:
" After considerable discussion, it was agreed that RFC822 users should be
able to address X.400 recipients in RFC822/Internet terms. This
implies the necessity of maintaining and distributing address mapping
tables to all participating RFC987 gateways, at least in the short term.
Other mapping strategies were discussed (loudly and enthusiastically), but
it was shown that these alternate strategies would sometimes cause
messages (or replies to messages) to pass through more than one gateway.
Since this behavior would probably cause information to be lost in
translation, it was quickly agreed that the alternate strategies were
inferior to the good old table driven approach.
Nevertheless, it was also pointed out that some X.400 addresses do
not map cleanly to RFC822 addresses, even when the table driven
mapping strategy is used. For example, X.400 personal names which
contain generation qualifiers, personal names which contain initials
but no given name, and initials which contain periods cannot be mapped
to RFC822 symmetrically such that a reverse mapping is possible.
Similarly, X.400 addresses which contain X.121 address elements
(sometimes used for expressing fax telephone numbers), unique UA
identifiers, or physical addressing attributes cannot be mapped nicely.
Consequently, it will be necessary for RFC987 gateways to generate RFC987
address syntax occasionally.
It was recommended that our RFC should contain guidelines for the
creation of X.400 personal names. In following these guidelines,
users will avoid creating personal names which can not be mapped
nicely between X.400 and RFC822.
It was generally agreed that long term reliance upon static mapping
tables is unacceptable. Therefore, it was agreed that the X.400
Operations Working Group should devise a strategy for using X.500
directory services instead.
Another option could be to use the DNS system for this purpose, if the
X.500 infrastructure appears to be too premature."
In other words, in most of the cases RFC-822 users will not see the
difference between an RFC-822 address and an X.400 address. Example:
The X.400 address:
C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=Jordan; G=Kevin
will from an RFC-822 user look like:
Kevin.Jordan@cpg.cdc.com
The mapping tables in the gateways will describe this mapping.
The other way around, an X.400 user, will normally see the difference of
an X.400 address and an RFC-822 address, because the RFC-822 address will
be using PRMD=Internet and dd.RFC-822 (example):
The RFC-822 address:
ok@subdomain.edu
will from an X.400 user look like:
C=us; ADMD= ; PRMD=Internet; DD.RFC-822=ok(a)subdomain.edu
The decision to use Domain Defined Attributes (DDAs) requires modification
of the current mapping table coordination procedures defined by the
European RARE-WG1. Such modifications have already been discussed and some
proposals are on the table.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet X.400 Project Contact Points:
--------------------------------------
If you need information from the project, please look first in the
catalog.txt file in our file server and check if there are some documents
there that might give you the information you need.
To contact the project team, please use the coordinates in the beginning
of this Newsletter.
The following persons are working on the Internet X.400 Project:
Allan.Cargille@pilot.cs.wisc.edu
C=us; ADMD= ; PRMD=xnren; O=UW-Madison; OU=cs; S=Cargille; G=Allan
Rob Hagens <hagens@cs.wisc.edu>
C=us; ADMD= ; PRMD=Internet; DD.RFC-822=hagens(a)cs.wisc.edu
Alf.Hansen@pilot.cs.wisc.edu
C=us; ADMD= ; PRMD=xnren; O=UW-Madison; OU=cs; S=Hansen; G=Alf
Larry Landweber <lhl@cs.wisc.edu>
C=us; ADMD= ; PRMD=Internet; DD.RFC-822=lhl(a)cs.wisc.edu
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -smart@manta.mel.dit.csiro.au (Robert Smart) (05/21/91)
In article <910517112138*/G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS> Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) writes: > >" 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/ It is sensible to use c=us, but I hope x.400 mtas in other countries will have the sense to deliver to a local Internet gateway. A question: is it possible to use this address format as the X.400 address of X.400 mail users within the Internet? The reason I would like it done that way is that people would then have exactly the same address (modulo syntactic isomorphism) for both X.400 and rfc-822 mail. In fact I would like UAs in the Internet X.400 world to allow the above address to be entered as "user@some.place.edu". If we could switch to X.400 while keeping our familiar addresses then X.400 would have a MUCH better chance of being accepted. And I can't see any reason why not: it is not as if those cumbersome X.400 addresses were ever meant to be used by X.400 users. Bob Smart
smart@manta.mel.dit.csiro.au (Robert Smart) (05/21/91)
In article <910517112138*/G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS> Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) writes: > >These organizations can communicate with X.400 users in the R&D MHS >Service in the following countries: > >Austria, Australia, Belgium, Canada, Denmark, Germany, Finland, France, >Iceland, Ireland, Italy, The Netherlands, Norway, Portugal, Spain, Sweden, >Switzerland, United Kingdom, and Yugoslavia. > What is this R&D MHS in Australia? George? Bob Smart
ggm@brolga.cc.uq.oz.au (George Michaelson) (05/21/91)
smart@manta.mel.dit.CSIRO.AU (Robert Smart) writes: [alf hansen sez] >>Austria, Australia, Belgium, Canada, Denmark, Germany, Finland, France, >>Iceland, Ireland, Italy, The Netherlands, Norway, Portugal, Spain, Sweden, >>Switzerland, United Kingdom, and Yugoslavia. >> >What is this R&D MHS in Australia? George? >Bob Smart Don't look at me... I diddun' do nothing. Actually kre gateways OTC and other X.400 stuff into AARNet, and I guess you could say PP is sort-of active in AARN. I think this is a fudge though. Not a bad idea but... George -- G.Michaelson Internet: G.Michaelson@cc.uq.oz.au Phone: +61 7 365 4079 Postal: George Michaelson, the Prentice Centre, The University of Queensland, St Lucia, QLD Australia 4072.
Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (05/21/91)
Bob Smart writes: >> >>" 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/ > > It is sensible to use c=us, but I hope x.400 mtas in other countries will > have the sense to deliver to a local Internet gateway. They can either route the messages to a local gateway or send it to the U.S. on X.400 and they will be gatewayed in the U.S. The international R&D MHS Service should work out criterias assisting MTA managers to make the right routing choise. > > A question: is it possible to use this address format as the X.400 address > of X.400 mail users within the Internet? An X.400 user within the Internet has an X.400 address different from the one above. This X.400 address should be used by other X.400 users. Example: My X.400 address is C=us; ADMD= ; PRMD=xnren; O=UW-Madison; OU=CS; S=Hansen; G=Alf This is the address other X.400 users should use to reach me. I do not see how you can construct an address of the PRMD=Internet-form from this address. > The reason I would like it done that way is that people would then have > exactly the same address (modulo syntactic isomorphism) for both X.400 and > rfc-822 mail. In fact I would like UAs in the Internet X.400 world to allow > the above address to be entered as "user@some.place.edu". If we could > switch to X.400 while keeping our familiar addresses then X.400 would have > a MUCH better chance of being accepted. And I can't see any reason why not: > it is not as if those cumbersome X.400 addresses were ever meant to be used > by X.400 users. The X.400 address space will be different from the existing RFC-822 address space. From my example above: My X.400 address above contains UW-Madison instead of wisc (cs.wisc.edu is the "well-known' RFC-822 address), because UW-Madison tells more about the organization than wisc. However, seen from the RFC-822 world, my X.400 address will look similar to the "well-known" RFC-822 address for University of Wisconsin, Madison. This is defined by the ADDRESS MAPPING between X.400 and RFC-822. The current mapping for my X.400 address is Alf.Hansen@pilot.cs.wisc.edu and will be changed asap to Alf.Hansen@cs.wisc.edu and then my X.400 address looks exactly as the good old RFC-822 addresses SEEN FROM THE RFC-822 world. By doing this, people can move from their RFC-822 mailboxes into a new and hopefully better X.400 address space, but seen from their friends in the RFC-822 world, the address will still look the same. Best regards, Alf H.
Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (05/22/91)
Bob smart writes: >> >>These organizations can communicate with X.400 users in the R&D MHS >>Service in the following countries: >> >>Austria, Australia, Belgium, Canada, Denmark, Germany, Finland, France, >>Iceland, Ireland, Italy, The Netherlands, Norway, Portugal, Spain, Sweden, >>Switzerland, United Kingdom, and Yugoslavia. >> > >What is this R&D MHS in Australia? George? > >Bob Smart Perhaps I should have deleted Australia from the list, as I deleted Republic of Korea. They were both part of the R&D MHS Service, but have faked out. Perhaps we should use this oportunity to find out what the status is in Australia. The following is taken from the current COSINE MHS Documentation in Switzerland. As you see, kre is still noted as the contact person. Is there still some X.400 activity in Melbourne? If there is, we would very much like to connect directly to them, or any other X.400 activists on the Australian continent, from our Central U.S. MTA in Wisconsin. We are using RFC-1006/TCP/IP to interconnect our MTAs. Best regards, Alf H. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = This file contains all information for country = au = collected from subdirectories countries, org and = wep on the COSINE MHS file server. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = Country: au, file: /usr2/ftp/e-mail/COSINE-MHS/countries/au =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= #H DOC=COUNTRIES/AU; RES=Robert Elz; DAT=88.09.29; For Australia the following constitutes the R&D MHS Service: ------------------------------------------------------------ "EAN/V1": 1 MTA (See COUNTRIES.AU.AU.ORG "X.400/84": None and COUNTRIES.AU.AU.MTA) RFC-987 gateways: None Gateways from "EAN/V1" to RFC-world: OZ.AU gateway to OZ, NZ The X.400-based network is as follows: -------------------------------------- Network name: au Responsible organisation: Dept. of Computer Science, University of Melbourne, Parkville, Victoria, Australia. 3052 WEP: munnari.mu Operational status: operational Contact person, network: Robert Elz (+61 3 344 5225) kre@munnari.oz.au #R COPYRIGHT/USAGE NOTICE: #R ========================================================================== #R The information contained herein is prepared by the COSINE MHS project #R team for use by the European national R&D MHS managers. This documentation #R is also available to PTT's and other interested parties. #R #R The COSINE MHS project team cannot accept responsibility for errors in or #R omissions from this document or losses arising from it. #R #R IT IS STRICTLY PROHIBITED TO UTILIZE THIS #R INFORMATION FOR ANY COMMERCIAL PURPOSE. #R ==========================================================================
smart@manta.mel.dit.csiro.au (Robert Smart) (05/23/91)
Firstly I'd like to apologise for my message about the Australian situation. It was a Followup in news and I set the distribution to "aus". Possibly when news groups have pseudo-moderator addresses that lead to a mailing list gateway then the gateway should not accept messages with a restricted Distribution header. In article <910521115026*/G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS> Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) writes: > > Alf.Hansen@cs.wisc.edu > >and then my X.400 address looks exactly as the good old RFC-822 addresses >SEEN FROM THE RFC-822 world. But doesn't this mean that if someone in the X.400 world sends to C=us; ADMD= ; PRMD=Internet; dd.rfc-822=Alf.Hansen(a)cs.wisc.edu then the mail will go quite unnecessarily into rfc-822 format, then get converted back to X.400 format to get delivered to you in your X.400 UA. Not only is it unnecessary but it will result in lose of information at the gateway crossings. I maintain that it is _possible_ to devise an address format for the use of X.400 _internally_ in the Internet which is compatible with the rfc822-style-x400-address for the same person so that people can switch mail protocols without changing their external address in either realm. Now it is probably true that the dd.rfc-822 style is not ideal for this purpose, but I think it could work. >By doing this, people can move from their RFC-822 mailboxes into a new >and hopefully better X.400 address space, but seen from their friends >in the RFC-822 world, the address will still look the same. But the address by which you reach them from the X.400 side will change and people who use the old address will cause messages to go through 2 gateways and lose information. Also we are very dependant on static tables. And the question remains: is it really necessary for us to have these problems which are going to make transition much harder? Bob Smart
Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (05/23/91)
Bob Smart writes: > > > > Alf.Hansen@cs.wisc.edu > > > >and then my X.400 address looks exactly as the good old RFC-822 addresses > >SEEN FROM THE RFC-822 world. > > But doesn't this mean that if someone in the X.400 world sends to > > C=us; ADMD= ; PRMD=Internet; dd.rfc-822=Alf.Hansen(a)cs.wisc.edu > > then the mail will go quite unnecessarily into rfc-822 format, then > get converted back to X.400 format to get delivered to you in your > X.400 UA. Not only is it unnecessary but it will result in lose of > information at the gateway crossings. I would say that if an X.400 user uses the X.400 address above to reach me, he is not using my correct address. May be the message will come through anyway, I have not tested it, but that is just accidental. My correct X.400 address is C=us; ADMD= ; PRMD=xnren; O=UW-Madison; OU=cs; S=Hansen; G=Alf seen from the RFC-822 world as: Alf.Hansen@pilot.cs.wisc.edu > I maintain that it is _possible_ to devise an address format for > the use of X.400 _internally_ in the Internet which is compatible > with the rfc822-style-x400-address for the same person so that > people can switch mail protocols without changing their external > address in either realm. > > Now it is probably true that the dd.rfc-822 style is not ideal > for this purpose, but I think it could work. You should come up with a concrete proposal and present it to the ietf-osi-x400ops@pilot.cs.wisc.edu distribution list. > >By doing this, people can move from their RFC-822 mailboxes into a new > >and hopefully better X.400 address space, but seen from their friends > >in the RFC-822 world, the address will still look the same. > > But the address by which you reach them from the X.400 side will > change and people who use the old address will cause messages to > go through 2 gateways and lose information. Also we are very dependant > on static tables. And the question remains: is it really necessary > for us to have these problems which are going to make transition > much harder? You are right that people will change addresses, at least seen from X.400, when they move to an X.400 mailbox. If people in the X.400 world start to use the correct address, the messages will not pass gateways twice. If they use the wrong address, you are right. Your point is relevant, and has been discussed, and the conclusion was that we want to build up a new address space for X.400 reflecting the actual organizational structure in the X.400 address attributes. There may be some transition problems, but since the X.400 user population at least in the U.S. for the moment is very small, compared to the RFC-822 user population, it was found more important to minimize the transition problems seen from the RFC-822 world. Best regards, Alf H.
Christian.Huitema@mirsa.inria.fr (Christian Huitema) (05/23/91)
Alf, Similarly to the "X.400 to Internet" problem, we may have to face a "Internet to X.400" problem someday. If you make the assumption that users dont have access to mapping table, then the Internet equivalent of: /c=us/admd= /prmd=Internet/dd.RFC-822=user(a)some.place.edu/ Is a gatewayed X.400 address, e.g. something as: /C=us/ADMD= /PRMD=xnren/O=UW-Madison/OU=CS/S=Hansen/G=Alf/@x400.net Were the domain <x400.net> designates the x400 world for Internet users, on the same way that "/c=us/admd= /prmd=Internet/" designates the Internet world for X.400 users. CAVEAT: there is no such thing as an <x400.net> know. This address is invalid. It is only an example. Dont use it. In fact, there no such thing as a fully connex X.400 net know, and one as to pick up "the right gateway". Christian Huitema
gih900@sao.aarnet.edu.au (05/28/91)
In article <910521121025*/G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS>, Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) writes: > Bob smart writes: >>> >>>These organizations can communicate with X.400 users in the R&D MHS >>>Service in the following countries: >>> >>>Austria, Australia, Belgium, Canada, Denmark, Germany, Finland, France, >>>Iceland, Ireland, Italy, The Netherlands, Norway, Portugal, Spain, Sweden, >>>Switzerland, United Kingdom, and Yugoslavia. > > Perhaps I should have deleted Australia from the list, as I deleted > Republic of Korea. They were both part of the R&D MHS Service, but have > faked out. > > Perhaps we should use this oportunity to find out what the status is in > Australia. The following is taken from the current COSINE MHS > Documentation in Switzerland. As you see, kre is still noted as the > contact person. Essentially this is the case right now - there is an operational gateway operated by kre which has a production gateway role between a commercial X.400 service and the Australian Internet mail domain, and there is also a continuation of the research role which was listed in the COSINE information package (although this is not an intense area of active development right now as I understand, or even of very active use). I would suggest that the entry be left as is for the moment - it is likely that some of the work which relates to the various COSINE sponsored activites in Europe and IETF activities in the States in terms of X.400 activity in Australia may be taken up as an active developmental project by more Australian sites in the near future, but right now the information is basically correct. regards, Geoff Huston Network Technical Manager, Australian Academic and Research Network