[Ediint] Re: Structure of an Internet EDI MIME Message

[Asger Smidt <[e-mail]>]

>All MIME content types SHOULD be supported with unknown types treated as "application/octet-stream". The following MUST be supported...

Well, yes, except that both "supported" and "treated as" are meaningless terms in this context, because the protocol does not "treat" different content types in different ways. The ONLY way the protocol interacts with the content type is if the implementer specifically makes it do so, and I am fairly certain that the spec makes no mention of how different content types should be "treated".

I imagine the original text was born out of the common usage of the protocol at the time, with no particular thought given to whether or not it actually made sense in the long run. As Marc pointed out, just in the application/ category there are now 1808 registered content types, and more will be coming. It seems incredibly pointless to try to force any kind of awareness of the content type into the protocol itself. As I said earlier it can make sense for a given implementation to enforce content type restrictions based on the capabilities of the receiving system, but that should not affect the protocol itself other than perhaps mentioning that this is allowed, if indeed we think it should be allowed. I think it should be, again because we cannot take the specifics of all current and future content types into account. With something like EDIFACT, which contains established acknowledgement messages, there is no need for the protocol to be involved in the message flow other than acting as the transport layer, but for other content types the MDN is the only ACK/NACK available in the flow. I believe that is the reason the "Failure: unsupported format" error message MUST be supported (chapter 8.5.3), precisely to give implementers this option.

-----Original Message-----
From: Erik Wramner <[e-mail]> 
Sent: Thursday, 24 September 2026 09.36
To: Asger Smidt <[e-mail]>; Marc Blanchet <[e-mail]>
Cc: [e-mail]
Subject: RE: [Ediint] Re: Structure of an Internet EDI MIME Message

Agreed, but the old standard did point out a few required content types explicitly. We could write this for the new standard:

--
All MIME content types SHOULD be supported with unknown types treated as "application/octet-stream". The following MUST be supported...
--

Alternatively, we could say that all content types not interfering with AS/2 (i.e., none of the container types) MUST be supported as binary data. The key to get across is that this should work as any other transmission protocol sending messages/files from A to B in binary form and it is an added bonus if the new standard is as close to the old one as possible except where it actually needs to change something. In my view this already works in most cases, so it does not need fixing.

-Erik

-----Original Message-----
From: Asger Smidt <[e-mail]> 
Sent: Thursday, 24 September 2026 09:26
To: Erik Wramner <[e-mail]>; Marc Blanchet <[e-mail]>
Cc: [e-mail]
Subject: RE: [Ediint] Re: Structure of an Internet EDI MIME Message

If I may weigh in here, my perspective is that AS2 is a transport protocol, completely separate from the payload it transports. I don't see that it makes sense to talk about which content types the protocol supports, because in my view the protocol and the payload do not interact with each other in any way. I think any protocol implementation that is hard coded to accept only certain content types is a very poor implementation indeed. I will happily admit that there are legitimate scenarios where it can make sense to limit the incoming content types through configuration, but that is not related to the protocol itself, but rather to the capabilities of the system behind the implementation that is ultimately receiving the data.

So, to sum up my position:
Technically I think the protocol should support all content types. However, given the non-interaction between the payload and protocol, the only form of "support" the protocol has to provide is to not explicitly filter out content types other than those on a specific list. In other words, as an implementer all I have to do to provide support for a given content type is to not explicitly block it, meaning I actually have to do nothing at all. As such, having the spec talk about what I MUST and SHOULD support is kind of a moot point, because I have no intention of going out of my way to make my AS2 framework less useful by deliberately restricting it from receiving certain content types. Never mind that there is no guarantee that the stated content type actually matches the payload. It is not up to the transport protocol to determine that however, its job is just to facilitate the transport of the payload from party A to party B in a secure manner.

/Asger

-----Original Message-----
From: Erik Wramner <[e-mail]> 
Sent: Thursday, 24 September 2026 07.49
To: Marc Blanchet <[e-mail]>
Cc: [e-mail]
Subject: [Ediint] Re: Structure of an Internet EDI MIME Message

>Great for you. That is an implementation choice. The point here is about the proposed sentence: "Although all MIME content types SHOULD be supported, the following MIME content types MUST be supported:".
>I suggested to remove "Although all MIME content types SHOULD be supported" as it is way too much. If an implementation supports everything, then fine. This is not what I'm talking about.

Well, it is what I am talking about. Interoperability. If our AS/2 customers connect to someone else, they want to be able to send their files. They want to trust that it works. If they can't do that, they will fall back to SFTP or some other protocol that does the job. Having this SHOULD in the standard increases the likelihood that a new server implements this correctly and just works. "It works if everyone has our server" or "products from vendor A, B or C" makes the standard moot.

HTTP is not limited to a few content types; it supports them all. SFTP is not limited to a few content types (albeit it is not based on MIME, it is a main competitor to AS/2 in practice). I don't see why AS/2 which builds on HTTP should be more restricted.

-Erik
_______________________________________________
Ediint mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]