GRZ027%DBNGMD21.BITNET@cunyvm.cuny.edu (Peter Sylvester +49 228 8199645) (10/23/90)
I am sending this message to a wider list since it seems that
the other channels don't work.
--
I am operating an X.400 system which also contains a gateway between
EARN/BITNET/Internet and X.400. Since some time I am serving a larger
community that wants to communicate with other european countries
through the RARE managed WEPS. I have noticed that many gateways
that serve as a "uucp"-X.400 bridge are creating invalid X.400
protocol elements. All theses systems are EAN. The two protocol
violations are:
user agent content id is > 16 characters and contain
non printable strings
IP message id contains non printable strings
Example: <57575.6576576@domain.something&cc>
From the data it is obvious that some RFC822 Message-id field
is used ASIS and put into both fields without going to the
required RFC987 encoding for messageids. Thus similar behaviour
is seen for all IP heading fields that contain a message id
(reply-to obsoletes).
I have tried to reach developers, maintainers of EAN and
DFN/EAN software since more than two years now to fix these
errors with partial success only. I assume that the RARE MHS
project and the UUCP/X.400 gateway operators are interested in
providing a service that does not lead to problems in other
areas. End users are complaining about the poor quality of
X.400.
The most recent problems came from the MHS-relay for AC.UK and
some norwegian uucp-ean gateway but I assume that all other
european ean based uucp/x.400 gateways are similar.
It is a pity to see the poor quality of the systems used in Europe in
order to demonstrate the usability and benefits of X.400. It is
worse than using a "Trabant" to demonstrate any quality of a car.
The developer of the Trabi please excuse this comparison.
--
I have been trying to use the RARE MHS project RFC987 tables in
order to configure my "internet-x.400" gateway.
This simply doesn't work.
There are some RFC822 domains that are no valid Internet
domains, like BITNET, EARN, MFENET, HEPNET and others. It
seems to me that theses tables are more suitable for gateways
between EARN/BITNET and the european RARE X.400 like networks,
but even this assumption is quite correct. The "gateway style"
addressing with prmd=domain and ONE country/admd combination
for several countries is not complete and consistent. There is
also at least one domain, i.e. EARN that does not exist
anywhere in BITNET or Internet.
I would like to know these tables are setup and coordinated between
whoever is supposed to be "the RFC822 partner network".
I know that there exist two different views about these "partners":
- As defined in RFC987: The tables consist of officially registered
Internet domains, and associated X.400 attributes that are
also more or less officially defined by someone.
This view means the for example European systems are all real
X.400 and there is "the other world" in Internet which may be
either separate or partially overlap (at least from an
administrational standpoint).
The partner in this case is "internet" or may EARN/BITNET.
- The other view is that the tables are only used to provide
access from isolated local area networks in Europe that are
connected via a local RFC987 gateway, and the tables contain
1-1 mappings as far as possible. This technique is necessary
for example for all the older EANS that are operated with
domain style names. No partner realy exists in this case. I
do not want to create a full list of all the problems created
by this view to end users and mail system providers. Just a
question: How would the Internet-X.400 gateway providers
coordinate the name spaces?
Correcting the errors in the RFC987 tables using other knowledge
is not a task that should be done by each mail system provider.
It would be unfair to say that the tables contain pure garbage.
Also some pregress seem to have been possible since the quality
is getting between.
Any comment is appreciated.
Peter Sylvester GMD BonnAlf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (10/24/90)
Peter, I think your comments are important and should be addressed to RARE WG1 or the RD-MHS Managers. Most of them are probably reading MHSnews as well, but it does not harm to address the lists directly. Have you tried to rise these questions before with no results? I can give you my comments to some of your statements: > I am operating an X.400 system which also contains a gateway between > EARN/BITNET/Internet and X.400. Since some time I am serving a larger > community that wants to communicate with other european countries > through the RARE managed WEPS. Good. Then you make sure that this "larger community" (I assume it is an international community) approaches their respective national networking organisation, ex. DFN i Germany, UNINETT in Norway, Janet in UK etc. They will do what they can to integrate your X.400 structure into the existing one. > I have noticed that many gateways > that serve as a "uucp"-X.400 bridge are creating invalid X.400 > protocol elements. All theses systems are EAN. The two protocol > violations are: > > user agent content id is > 16 characters and contain > non printable strings > > IP message id contains non printable strings > > Example: <57575.6576576@domain.something&cc> > > From the data it is obvious that some RFC822 Message-id field > is used ASIS and put into both fields without going to the > required RFC987 encoding for messageids. Thus similar behaviour > is seen for all IP heading fields that contain a message id > (reply-to obsoletes). This is a typical problam that should be discussed with the R&D-MHS Managers. If current systems are violating the standards, we should at least explain why, or what we are going to do to fix it. > I have tried to reach developers, maintainers of EAN and > DFN/EAN software since more than two years now to fix these > errors with partial success only. I assume that the RARE MHS > project and the UUCP/X.400 gateway operators are interested in > providing a service that does not lead to problems in other > areas. End users are complaining about the poor quality of > X.400. If these gateways are official RFC 987 gateways, I am sure the operators want to provide a high quality service. There are, however, a number of ad hoc gateway solutions in operation, and I am not sure if it is possible to improve the qos at these points. At least, the R&D MHS Service has identified the existing official gateways, and if they are causing trouble, somebody will look into it. > I have been trying to use the RARE MHS project RFC987 tables in > order to configure my "internet-x.400" gateway. > > This simply doesn't work. > > There are some RFC822 domains that are no valid Internet > domains, like BITNET, EARN, MFENET, HEPNET and others. It > seems to me that theses tables are more suitable for gateways > between EARN/BITNET and the european RARE X.400 like networks, > but even this assumption is quite correct. The "gateway style" > addressing with prmd=domain and ONE country/admd combination > for several countries is not complete and consistent. There is > also at least one domain, i.e. EARN that does not exist > anywhere in BITNET or Internet. I am not sure if I got your point correctly, but this "stupid" situation with c=no: prmd=earn: etc. is not a desired situation. Nobody wants it. Unregistrered domains must live with some problems until they define their own mapping or integrate their address space with the existing RFC 822 space under top level domain country. Ex. an EARN address in Norway may look like user@bi.no. There are also registered top domains with undefined mappings. When they have defined their mapping, this problem will disappear. If you have a proposal for a better way to solve this ensuring connectivity and not violating other bodies authorities, I am sure many people will be glad to hear about it. > I would like to know these tables are setup and coordinated between > whoever is supposed to be "the RFC822 partner network". > I know that there exist two different views about these "partners": > > - As defined in RFC987: The tables consist of officially registered > Internet domains, and associated X.400 attributes that are > also more or less officially defined by someone. > This view means the for example European systems are all real > X.400 and there is "the other world" in Internet which may be > either separate or partially overlap (at least from an > administrational standpoint). > The partner in this case is "internet" or may EARN/BITNET. > > - The other view is that the tables are only used to provide > access from isolated local area networks in Europe that are > connected via a local RFC987 gateway, and the tables contain > 1-1 mappings as far as possible. This technique is necessary > for example for all the older EANS that are operated with > domain style names. No partner realy exists in this case. I > do not want to create a full list of all the problems created > by this view to end users and mail system providers. Just a > question: How would the Internet-X.400 gateway providers > coordinate the name spaces? Just for information: The RARE MHS Project has coordinated the collection and distribution of these tables for several years. You should contact your X.400 operators in DFN, or at GMD and ask for more information. You can also contact c=no; prmd=uninett: o=rare; s=mhs-project-team mhs-project-team@rare.no and ask for info about procedures etc. > Correcting the errors in the RFC987 tables using other knowledge > is not a task that should be done by each mail system provider. > It would be unfair to say that the tables contain pure garbage. > Also some pregress seem to have been possible since the quality > is getting between. I am sure the R&D MHS Managers or RARE WG1 will discuss proposals for modifications in the current procedures seriously. Best regards, Alf H. XNREN Manager