Anyone heard of the X.400 protocol?
-
I'd never heard of it, but according to the sparse information I can find it's a sort private e-mail network that predates e-mail. Apparently it's "popular" for EDI exchange and not much else (although the military and NATO use it, among others, because it's more secure than e-mail). I just got a question from a client if I can deliver an EDI message via ATLAS400 instead of regular e-mail. Seriously, as soon as someone mentions EDI I get shivers down my spine. How can something be so ridiculously obscure and complicated and yet so popular!? :~ A simple OpenAPI specification would've done the trick! (I know, EDI predates REST, JSON, SOAP and even XML...) Anyway, it seems I need some subscription to an X.400 service and even then, there are 0 code examples on the entire internet... So much for "industry standard" X|
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Oh man now I feel old. I think we used that on AIX machines in the early 90's. Good luck! You've got this! :-D
cheers Chris Maunder
-
I'd never heard of it, but according to the sparse information I can find it's a sort private e-mail network that predates e-mail. Apparently it's "popular" for EDI exchange and not much else (although the military and NATO use it, among others, because it's more secure than e-mail). I just got a question from a client if I can deliver an EDI message via ATLAS400 instead of regular e-mail. Seriously, as soon as someone mentions EDI I get shivers down my spine. How can something be so ridiculously obscure and complicated and yet so popular!? :~ A simple OpenAPI specification would've done the trick! (I know, EDI predates REST, JSON, SOAP and even XML...) Anyway, it seems I need some subscription to an X.400 service and even then, there are 0 code examples on the entire internet... So much for "industry standard" X|
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
It rings a bell. Maybe bank networks, like ATM machines use it? IDK. I just think it sounds familiar. NVM, I'm thinking of something else.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I'd never heard of it, but according to the sparse information I can find it's a sort private e-mail network that predates e-mail. Apparently it's "popular" for EDI exchange and not much else (although the military and NATO use it, among others, because it's more secure than e-mail). I just got a question from a client if I can deliver an EDI message via ATLAS400 instead of regular e-mail. Seriously, as soon as someone mentions EDI I get shivers down my spine. How can something be so ridiculously obscure and complicated and yet so popular!? :~ A simple OpenAPI specification would've done the trick! (I know, EDI predates REST, JSON, SOAP and even XML...) Anyway, it seems I need some subscription to an X.400 service and even then, there are 0 code examples on the entire internet... So much for "industry standard" X|
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
X.4nn are ISO standards that describe mail systems at various levels. I assume ATLAS 400 is a product/service that supports X.400 messaging and then the question becomes how do you interface with it. Back in the day the X.400 systems I worked with (ISOCOR, Exchange) had file gateways, you simply prepared a valid X.400 binary object and that was picked up by the mail server. ATLAS 400 may have other options, their website is in French so I can't tell. If you need to generate X.400 objects then you'll see the standard is complicated, like all international standards, but since you're presumably only sending, and fairly simple e-mails at that, you only need to cover a limited subset. If you can't find any libraries that you can use I may be able to dig up some old code (25 years+, plain C) that might be of help. Writing it from scratch isn't terrible if you're used to reading standards, BNF etc. I assume the EDI part is a solved problem. You probably don't want to write your own code for that.
-
I'd never heard of it, but according to the sparse information I can find it's a sort private e-mail network that predates e-mail. Apparently it's "popular" for EDI exchange and not much else (although the military and NATO use it, among others, because it's more secure than e-mail). I just got a question from a client if I can deliver an EDI message via ATLAS400 instead of regular e-mail. Seriously, as soon as someone mentions EDI I get shivers down my spine. How can something be so ridiculously obscure and complicated and yet so popular!? :~ A simple OpenAPI specification would've done the trick! (I know, EDI predates REST, JSON, SOAP and even XML...) Anyway, it seems I need some subscription to an X.400 service and even then, there are 0 code examples on the entire internet... So much for "industry standard" X|
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Certainly not "private" email! One of the reasons why it was rejected by the internet community around 1990 was that is assumed a public infrastructure comparable to the paper mail system, with post offices run by recognized authorities, strict tests for conformance before you were recognized by the post office, etc. X.400 was standardized in 1984, with a revision in 1988 that still holds up today. (There are a few updates since, but they are rather insignificant.) From the first (1984) version, it fully handled binary body parts. All attribute strings use 8 bit character sets, transmitted in a Tag-Length-Value format, so there is never any need for quoting or escaping. Encrypted mail was included from the very first version, and with that: Authentication. As the mail transfer is done through a network of publicly recognized agents, you cannot fake mail: The transfer network knows where it was submitted, and verifies that the sender identification corresponds to the identity of the submitter (you must present an ID when submitting mail), so tracing/curbing a spammer would be quite simple. The message transfer service can provide a delivery report (for non-repudiation purposes), both when the message is delivered from the transfer service to the recipient's mailbox and when the user fetches it from the mailbox into his reader. A related service: You can submit a message for delivery at a specific time: The message transfer service holds it back at the target "post office" until the specified time, when it is delivered to the recipient's mailbox. If you change your mind before the delivery time is up, you can recall the message, and it is not delivered. (In the old days, the postal system had this service for paper mail as well: You could request a given delivery time, as well as recall mail not yet delivered.) Chances are that you have used X.400! The major change from the 1984 to the 1988 version was not much on the functional side, but a complete reorganization of the standard content. So the directory service, developed for the address format of X.400 email, and first a part of the X.400 standard, was split off as X.500 in the 1988 version. The internet community didn't have any directory system comparable to X.500 (or if you like: X.400-and-something; I don't have that version available, but X.421 rings a bell; that may be wrong), so they developed an IP-based protocol based on X.500, leaving out the parts too complex to be implemented by sophomore or junior IT students, and called it LD
-
I'd never heard of it, but according to the sparse information I can find it's a sort private e-mail network that predates e-mail. Apparently it's "popular" for EDI exchange and not much else (although the military and NATO use it, among others, because it's more secure than e-mail). I just got a question from a client if I can deliver an EDI message via ATLAS400 instead of regular e-mail. Seriously, as soon as someone mentions EDI I get shivers down my spine. How can something be so ridiculously obscure and complicated and yet so popular!? :~ A simple OpenAPI specification would've done the trick! (I know, EDI predates REST, JSON, SOAP and even XML...) Anyway, it seems I need some subscription to an X.400 service and even then, there are 0 code examples on the entire internet... So much for "industry standard" X|
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
It has been operating for decades without reinventing the wheel at the arrival of new paradigms so it is well thought out and designed. Besides that, nothing that works is simple.
-
Certainly not "private" email! One of the reasons why it was rejected by the internet community around 1990 was that is assumed a public infrastructure comparable to the paper mail system, with post offices run by recognized authorities, strict tests for conformance before you were recognized by the post office, etc. X.400 was standardized in 1984, with a revision in 1988 that still holds up today. (There are a few updates since, but they are rather insignificant.) From the first (1984) version, it fully handled binary body parts. All attribute strings use 8 bit character sets, transmitted in a Tag-Length-Value format, so there is never any need for quoting or escaping. Encrypted mail was included from the very first version, and with that: Authentication. As the mail transfer is done through a network of publicly recognized agents, you cannot fake mail: The transfer network knows where it was submitted, and verifies that the sender identification corresponds to the identity of the submitter (you must present an ID when submitting mail), so tracing/curbing a spammer would be quite simple. The message transfer service can provide a delivery report (for non-repudiation purposes), both when the message is delivered from the transfer service to the recipient's mailbox and when the user fetches it from the mailbox into his reader. A related service: You can submit a message for delivery at a specific time: The message transfer service holds it back at the target "post office" until the specified time, when it is delivered to the recipient's mailbox. If you change your mind before the delivery time is up, you can recall the message, and it is not delivered. (In the old days, the postal system had this service for paper mail as well: You could request a given delivery time, as well as recall mail not yet delivered.) Chances are that you have used X.400! The major change from the 1984 to the 1988 version was not much on the functional side, but a complete reorganization of the standard content. So the directory service, developed for the address format of X.400 email, and first a part of the X.400 standard, was split off as X.500 in the 1988 version. The internet community didn't have any directory system comparable to X.500 (or if you like: X.400-and-something; I don't have that version available, but X.421 rings a bell; that may be wrong), so they developed an IP-based protocol based on X.500, leaving out the parts too complex to be implemented by sophomore or junior IT students, and called it LD
trønderen wrote:
One thing that is not clear to me: You can develop an EDI application, and feed it through your mailbox to the X.400 network. But: Is there an X.400 network you can mail it to? I am not familiar with ATLAS400, it seems to be an X.400 network of sorts, but how can you access it? How can the customer access it?
My customer now gets some EDI file (that is a .txt file with the cryptic contents that make up an EDI message) from some application and they simply e-mail it to their customer. Now the customer has requested to get it through ATLAS400, but none of us heard about it and they simply asked me if I knew it and if I could do it. My answer will be "no" :laugh: I mean, I could do it, given enough time and money, but for that single (probably monthly) file, it's simply not worth it. Thanks for the history lesson though!
trønderen wrote:
Certificates for e.g. TLS authentication/encryption are called "X.509 certificates".
This one blew my mind! :omg:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
X.4nn are ISO standards that describe mail systems at various levels. I assume ATLAS 400 is a product/service that supports X.400 messaging and then the question becomes how do you interface with it. Back in the day the X.400 systems I worked with (ISOCOR, Exchange) had file gateways, you simply prepared a valid X.400 binary object and that was picked up by the mail server. ATLAS 400 may have other options, their website is in French so I can't tell. If you need to generate X.400 objects then you'll see the standard is complicated, like all international standards, but since you're presumably only sending, and fairly simple e-mails at that, you only need to cover a limited subset. If you can't find any libraries that you can use I may be able to dig up some old code (25 years+, plain C) that might be of help. Writing it from scratch isn't terrible if you're used to reading standards, BNF etc. I assume the EDI part is a solved problem. You probably don't want to write your own code for that.
gthp_cp wrote:
I may be able to dig up some old code (25 years+, plain C) that might be of help.
Thanks for the offer! We've decided this single file isn't worth all this trouble though, so I won't be needing it.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Oh man now I feel old. I think we used that on AIX machines in the early 90's. Good luck! You've got this! :-D
cheers Chris Maunder
Chris Maunder wrote:
Good luck! You've got this! :-D
No I don't! :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
It has been operating for decades without reinventing the wheel at the arrival of new paradigms so it is well thought out and designed. Besides that, nothing that works is simple.
I can't think of anything that is well thought out and designed, yet has made a great success in the IT/networking world. All the well designed languages flopped. All the well designed data representation formats. All the well designed protocols. People do not want good design. IT people in particular, but certainly not limited to them. No well designed human language has made any great success, either!
Religious freedom is the freedom to say that two plus two make five.
-
Oh man now I feel old. I think we used that on AIX machines in the early 90's. Good luck! You've got this! :-D
cheers Chris Maunder
And on the IBM AS400 Series. I remember as a young "tech" , working for a company that made rubber gaskets for the auto industry. They used to exchange orders with their European partners every night, it used to take 9 hours to exchange all these massive EDI documents, which then took another 3 to 4 hours in a complex COBOL driven process to turn the data into a human readable format. We'd set the transfer going at 5pm when everyone left the office for the night, and it would be just finishing at about 9am the next morning as everyone started to filter in for the day.
-
And on the IBM AS400 Series. I remember as a young "tech" , working for a company that made rubber gaskets for the auto industry. They used to exchange orders with their European partners every night, it used to take 9 hours to exchange all these massive EDI documents, which then took another 3 to 4 hours in a complex COBOL driven process to turn the data into a human readable format. We'd set the transfer going at 5pm when everyone left the office for the night, and it would be just finishing at about 9am the next morning as everyone started to filter in for the day.
Another nighttime story ... In 1983 (*), I started working in a company developing an X.400 system. Testing interaction with other systems was essential, so those of us who kept up old contacts at our alma mater was welcome to keep in X.400 contact with them - the University ran a different X.400 implementation. The underlaying network wasn't perfectly stable, so every now and then, messages didn't make it. One day we had a huge rush of incoming messages, some of them months old. All the missing ones were there. Where had they hidden in the weeks before? It took a while before we found an explanation. When the University mail system failed delivery, it was configured to make a new try later - at midnight. At our company, a raw disc offline backup copy was made every day, or rather: every night, starting at midnight. So when the MTA at the U made another attempt at midnight, night after night, our mail machine was just taken down for backup. One evening, our mail machine had a total crash. As it was already down, the operators decided to make the backup a couple hours early. The machine was back on air before midnight, ready to receive all the failing messages for months from the university. It took yet a couple days before anyone connected the early backup to the rush of emails, but when someone suggested it, the connection was obvious. (*) Some people claim that while internet protocols are based on real experience, real testing, OSI standards are just paperwork that never works in practice. That is of course far from truth. This was in 1983, a year before the fist official X.400 standard was passed. There were (at least) two complete, independent implementations available for testing. But, being ahead of time can be costly. My company obviously based the implementation on working drafts. For a couple years, the drafts for the directory functions (then still part of X.400 - later to be split off as X.500) was quite stable, the implementation was based on that. A few months before the finalizing of the official standard, a major part of the directory drafts was ditched, and another alternative pulled in. My company had to do a huge crash job to implement the other alternative, the one in the final standard. (Obviously, proponents of this other alternative were from companies who had a running implementation of that alternative ready. In order to be competitive, my company had to offer the standard solution as soon as possible, not something of their own, before the competition took over the mar
