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

[Erik Wramner <[e-mail]>]

Regarding 4K video MIME types, we have customers using them - a lot. We do support all MIME types except the ones that conflict with AS/2 itself. As we are supposed to deliver the content byte-by-byte exactly as it was received, this is not a problem. I'd like to keep the sentence.

However, I wanted to remove all the "optional RFC3274 (CompressedData)" parts and instead create examples with and without for clarity. I can do the editing if you like, Debra?

I'm still in favor of keeping both compression alternatives and I don't agree on the conclusion. I think the example demonstrated that compressing the signed data (with base64-encoded signature which is what almost everyone is using) actually does produce a smaller message than compressing the content and having the base64 data uncompressed. Furthermore, that example did not include the HTTP headers inside the MIME parts. They compress quite well, so compressing the signed data gets even better. This is not super important, but I think we should keep it as it is. Existing products already support this, and new products will have to do it to handle older AS/2 versions anyway. Having a new AS/2 product that is not able to communicate with old servers would be unacceptable in my book. We can write that new products SHOULD compress the innermost part (content) when sending, but that they MUST handle any order on receive.

-Erik

-----Original Message-----
From: Debra Petta <debrap=[e-mail]> 
Sent: Wednesday, 23 September 2026 19:31
To: Marc Blanchet <[e-mail]>; Debra Petta <debrap=[e-mail]>
Cc: [e-mail]
Subject: [Ediint] Re: Structure of an Internet EDI MIME Message

Marc, 

I understand your point; however, I would like the rest of the implementors to weigh in before we pull out pieces that may still be needed.
I'd like to review the recording of our interim meeting so I can make notes of what we agreed to.  Is that available somewhere?

Regarding 4K video MIME types, if a vendor has a business need for sending it, there is no reason why AS2 should not support it -- just my opinion.

-Debra

-----Original Message-----
From: Marc Blanchet <[e-mail]>
Sent: Wednesday, September 23, 2026 11:50 AM
To: Debra Petta <debrap=[e-mail]>
Cc: [e-mail]
Subject: [Ediint] Re: Structure of an Internet EDI MIME Message

Some notes below.

> Le 23 sept. 2026 à 12:32, Debra Petta <debrap=[e-mail]> a écrit :
> 
> Based on all the comments so far, I reworked the content of the entire section (below). 
> The key notes section shows the required and optional content types.
>  Let me know if this is what you had in mind and if more changes are needed before I post a new copy of the draft.
> Also, are the RFCs in this section the correct/latest ones for the modern specification?
>  -Debra
>   4.2.  Structure of an Internet EDI MIME Message
>        No encryption, no signature, no compression
>          - RFC2616/2045 (HTTP/MIME)
>            - RFC1767/RFC3023 (payload content)
>        No encryption, signature, no compression
>          - RFC2616/2045 (HTTP/MIME)
>            - RFC1847 (multipart/signed)
>              - RFC1767/RFC3023 (payload content)
>              - RFC5751 (application/pkcs7-signature)
>        Encryption, no signature, no compression
>          - RFC2616/2045 (HTTP/MIME)
>            - RFC5751 (application/pkcs7-mime) (everything below inside this part is encrypted)
>              - RFC1767/RFC3023  (payload content)
>        Encryption, signature, no compression
>          - RFC2616/2045 (HTTP/MIME)
>            - RFC5751 (application/pkcs7-mime) (everything below inside this part is encrypted)
>              - RFC1847 (multipart/signed)
>                - RFC1767/RFC3023  (payload content)
>                - RFC5751 (application/pkcs7-signature)
>        No encryption, no signature (with optional compression)
>          - RFC2616/2045 (HTTP/MIME)
>            - [optional RFC3274 (CompressedData) (everything below inside this part is compressed)]
>              - RFC1767/RFC3023 (payload content)
>        No encryption, signature (with optional compression before signing)
>          - RFC2616/2045 (HTTP/MIME)
>            - [optional RFC3274 (CompressedData) (everything below inside this part is compressed)]
>              - RFC1847 (multipart/signed)
>                  - RFC1767/RFC3023 (payload content)
>                  - RFC5751 (application/pkcs7-signature)
>        No encryption, signature (with optional compression after signing)
>          - RFC2616/2045 (HTTP/MIME)
>            - RFC1847 (multipart/signed)
>              - [optional RFC3274 (CompressedData) (everything below inside this part is compressed)]
>                - RFC1767/RFC3023 (payload content)
>                - RFC5751 (application/pkcs7-signature)
>        Encryption, no signature (with optional compression)
>           - RFC2616/2045 (HTTP/MIME)
>             - RFC5751 (application/pkcs7-mime) (everything below inside this part is encrypted)
>               - [optional RFC3274 (CompressedData) (everything below inside this part is compressed)]
>                 - RFC1767/RFC3023 (payload content)
>        Encryption, signature (with optional compression before signing)
>          - RFC2616/2045 (HTTP/MIME)
>            - RFC5751 (application/pkcs7-mime) (everything below inside this part is encrypted)
>              - [optional RFC3274 (CompressedData) (everything below inside this part is compressed)]
>                - RFC1847 (multipart/signed)
>                  - RFC1767/RFC3023 (payload content)
>                  - RFC5751 (application/pkcs7-signature)
>        Encryption, signature (with optional compression after signing)
>          - RFC2616/2045 (HTTP/MIME)
>            - RFC5751 (application/pkcs7-mime) (everything below inside this part is encrypted)
>              - RFC1847 (multipart/signed)
>                - [optional RFC3274 (CompressedData) (everything below inside this part is compressed)]
>                - RFC1767/RFC3023 (payload content)
>                - RFC5751 (application/pkcs7-signature)
>        MDN over HTTP, no signature
>          - RFC2616/2045 (HTTP/MIME)
>            - RFC3798 (message/disposition-notification)
>        MDN over HTTP, signature
>          - RFC2616/2045 (HTTP/MIME)
>            - RFC1847 (multipart/signed)
>             - RFC3798 (message/disposition-notification)
>             - RFC5751 (application/pkcs7-signature)
>     *Key Notes*
>       o  RFC 3274 (CompressedData) is the normative reference for compression.
>       o  Compression MAY be combined with signing and/or encryption in either order,
>         but the choice affects what the digital signature covers.
>       o  Many implementations compress before signing and encrypting to maximize size
>         reduction, but compression after signing and before encrypting MUST also be supported.

Well, given that we are talking of a new protocol, therefore a new implementation (that may share code with AS2v1), I would suggest to restrict to only compression before signing and encryption. It makes implementations simpler, easier to test, less error-prone, less config panels, ... therefore costs less. Too many alternatives are often not useful. And as we have discussed, people may have used it (compression after signing/encrypt) in the past without really knowing that it may not be as good as the alternative.


>       o  Although all MIME content types SHOULD be supported, the following
>         MIME content types MUST be supported:

"Although all MIME content types SHOULD be supported": as written, this is impossible, not realistic and essentially dangerous. Do we want to support 4K Video MIME-types?

Suggest to drop that part of the sentence.

Marc.


>              Content-type: multipart/signed
>             Content-Type: multipart/report
>             Content-type: message/disposition-notification
>             Content-Type: application/PKCS7-signature
>             Content-Type: application/PKCS7-mime
>       o  Implementations SHOULD support the following content types based on
>         intended use:
>              Content-Type: application/EDI-X12 (for ANSI X12 EDI)
>             Content-Type: application/EDIFACT (for UN/EDIFACT EDI)
>             Content-Type: application/edi-consent
>             Content-Type: application/XML (for XML-based structured data)
>   From: Erik Wramner <[e-mail]>
> Sent: Wednesday, September 23, 2026 9:55 AM
> To: Russ Housley <[e-mail]>
> Cc: Asger Smidt <[e-mail]>; [e-mail]
> Subject: [Ediint] Re: Structure of an Internet EDI MIME Message 
> Agreed, but at the same time we don’t have to list all the supported content types everywhere. So:
>  RFC1767/RFC3023 (application/EDIxxxx or /xml)  Can either be left as 
> it is or we could replace it with:
>  RFC1767/RFC3023 (content, for example application/xml)  -Erik
>  From: Russ Housley <[e-mail]>
> Sent: Wednesday, 23 September 2026 16:41
> To: Erik Wramner <[e-mail]>
> Cc: Asger Smidt <[e-mail]>; [e-mail]
> Subject: Re: [Ediint] Structure of an Internet EDI MIME Message  I 
> think it is useful to list the MIME content types that MUST be supported, and the say other MIME content type MAY also be supported.  New MIME content types are registered all the time, so it is not practical to support all of them.
>  Russ
>   On Sep 23, 2026, at 6:28 AM, Erik Wramner <[e-mail]> wrote:
>  Our product supports any data as content. The old specification required support for a few specific types, quote:
>  --
> Although all MIME content types SHOULD be supported, the following MIME content types MUST be supported:
>  Content-type: multipart/signed
> Content-Type: multipart/report
> Content-type: message/disposition-notification
> Content-Type: application/PKCS7-signature
> Content-Type: application/PKCS7-mime
> Content-Type: application/EDI-X12
> Content-Type: application/EDIFACT
> Content-Type: application/edi-consent
> Content-Type: application/XML
> --
>  So, the content type in the example refers to these. We could just write “content” instead.
>  -Erik
>  From: Asger Smidt <[e-mail]>
> Sent: Wednesday, 23 September 2026 11:32
> To: Erik Wramner <[e-mail]>
> Cc: [e-mail]
> Subject: RE: Structure of an Internet EDI MIME Message  Actually, now 
> that I think about it:
>  Encryption, no signature, compression
>            - RFC2616/2045 (HTTP/MIME)
>               - RFC5751 (application/pkcs7-mime; smime-type=enveloped-data) (everything below inside this part is encrypted)
>                 - RFC3274 (application/pkcs7-mime; smime-type=compressed-data) (everything below inside this part is compressed)
>                   - RFC1767/RFC3023 (application/EDIxxxx or /xml)  If 
> I’m not mistaken this represents the actual payload, correct? Are there actually any restrictions on which types of payload you are allowed to send via AS2? Looking at this, I would interpret it as saying that you are not allowed to send for instance JSON data via AS2, but I don’t think that is actually an intended restriction. It might be a good idea to somehow make the text distinguish between requirements and examples, because this looks like a definite requirement, but I don’t think it is.
>  /Asger
>  From: Erik Wramner <[e-mail]>
> Sent: Wednesday, 23 September 2026 10.31
> To: Asger Smidt <[e-mail]>
> Cc: [e-mail]
> Subject: RE: Structure of an Internet EDI MIME Message  I agree, the 
> reference to HTTP/MIME is good. I have implemented HTTP more than once, but only HTTP 1.0 in the old days. Implementing 1.1 or better is another story entirely, way too much complexity there. This will be done by library code for sure.
>  -Erik
>  From: Asger Smidt <[e-mail]>
> Sent: Wednesday, 23 September 2026 10:17
> To: Debra Petta <debrap=[e-mail]>; Erik 
> Wramner <[e-mail]>
> Cc: [e-mail]
> Subject: RE: Structure of an Internet EDI MIME Message  Yes, this is 
> much better. It actually shows on which level the encryption takes place instead of at the bottom.
>  I might go so far as to add something like this:
>  Encryption, no signature, compression
>            - RFC2616/2045 (HTTP/MIME)
>               - RFC5751 (application/pkcs7-mime; smime-type=enveloped-data) (everything below inside this part is encrypted)
>                 - RFC3274 (application/pkcs7-mime; smime-type=compressed-data) (everything below inside this part is compressed)
>                   - RFC1767/RFC3023 (application/EDIxxxx or /xml) 
> Implementors usually use standard libraries for basic functionality. I don’t know anyone who has ever actually written an implementation of the HTTP protocol. I certainly haven’t. As such, expecting them to know offhand what a given RFC represents is probably unrealistic, because they rarely, if ever, have to consult actual RFCs in their daily work.
>  /Asger
>  From: Debra Petta <debrap=[e-mail]>
> Sent: Tuesday, 22 September 2026 19.44
> To: Erik Wrammer <[e-mail]>
> Cc: [e-mail]
> Subject: [Ediint] Re: Structure of an Internet EDI MIME Message  OK, 
> thanks Erik.
>  If there are no objections to this example, I replace it with the one in the draft.
>   From: Erik Wramner <[e-mail]>
> Sent: Tuesday, September 22, 2026 12:21 PM
> To: Debra Petta <[e-mail]>
> Cc: [e-mail]
> Subject: RE: Structure of an Internet EDI MIME Message  Hi Debra,  I 
> think I covered this in my example? To take Asger’s specific case then:
>  Encryption, no signature, compression
>            - RFC2616/2045
>               - RFC5751 (application/pkcs7-mime; smime-type=enveloped-data) (everything below inside this part is encrypted)
>                 - RFC3274 (application/pkcs7-mime; smime-type=compressed-data) (everything below inside this part is compressed)
>                   - RFC1767/RFC3023 (application/EDIxxxx or /xml) 
> Encryption, no signature, no compression
>            - RFC2616/2045
>               - RFC5751 (application/pkcs7-mime; smime-type=enveloped-data) (everything below inside this part is encrypted)
>                  - RFC1767/RFC3023 (application/EDIxxxx or /xml)  The 
> optional compression is split into two examples, one with and one 
> without. Much easier to read. The text “(encrypted)” is removed, but 
> “everything below inside this part is encrypted” added instead. We can 
> remove that if you feel it adds no value.  -Erik
>  From: Debra Petta <[e-mail]>
> Sent: Tuesday, 22 September 2026 18:38
> To: Erik Wramner <[e-mail]>
> Cc: [e-mail]
> Subject: RE: Structure of an Internet EDI MIME Message  Hi Erik,  I 
> have pasted the snippet of Asger’s original comment here for your review:
>  Another thing about section 4.2 is the way it indicates encryption:
>  >      Encryption, no signature (with optional compression)
> >          - RFC2616/2045
> >            - RFC5751 (application/pkcs7-mime)
> >              - [optional RFC3274 (CompressedData)]
> >                - RFC1767/RFC3023 (application/EDIxxxx or /xml)
> > (encrypted)
>  Here, as with the "Encryption, signature" section above, the layout 
> seems to indicate that encryption takes place in the innermost layer of the message, which is surely the exact opposite of the truth.
>  I will happily admit that maybe I just don't know how to properly 
> read a spec (I am still new to this deep level of the tech stack), but I do not think I am alone in this. When shown a hierarchy with the word "encrypted"
> on the bottom level, I think most people will conclude that that is 
> where the encryption takes place, rather than the top level.
>   From: Erik Wramner <[e-mail]>
> Sent: Tuesday, September 22, 2026 11:28 AM
> To: [e-mail]
> Subject: [Ediint] Structure of an Internet EDI MIME Message  In the 
> meeting Today, I promised to write something about the MIME structure. I can’t find the original post, but I think I remember what it was about. This is in “4.2.  Structure of an Internet EDI MIME Message”.
>  Simple example for reference:
>        No encryption, signature, no compression
>          - RFC2616/2045
>            - RFC1847 (multipart/signed)
>              - RFC1767/RFC3023 (application/EDIxxxx or /xml)
>              - RFC5751 (application/pkcs7-signature)  Here everything 
> is in plain text, so someone reading the HTTP request can see the XML or other content embedded inside the multipart message. Compare that with:
>        Encryption, no signature, no compression
>          - RFC2616/2045
>            - RFC5751 (application/pkcs7-mime)
>              - RFC1767/RFC3023  (application/EDIxxxx or /xml)
> (encrypted)  Here they want to show the structure in the same way with all the nested MIME types, but they also want to highlight that the content is encrypted and cannot be read if the message is intercepted. In other words, the “(encrypted)” part is just to inform the reader that the given MIME part is not sent in the clear; but encrypted by the enclosing container/envelope. I think this is fine, but it gets confusing when compression is added:
>        Encryption, signature (compression may occur before or after signing)
>          - RFC2616/2045
>            - RFC5751 (application/pkcs7-mime)
>              - [optional RFC3274 (CompressedData) if compress-before-sign]
>                - RFC1847 (multipart/signed) (encrypted)
>                  - [optional RFC3274 (CompressedData) if compress-after-sign]
>                  - RFC1767/RFC3023 (application/EDIxxxx or /xml) (encrypted)
>                  - RFC5751 (application/pkcs7-signature) (encrypted) 
> Not only is it very confusing to have two different compression stages in the same example, but if it says “encrypted” to show that an inner part is encrypted, then it should probably also say “compressed” for all inner parts that are compressed? They are not sent in the clear either, although there is no security.
>  My suggestion is to expand the examples with compression so that they cover the alternatives explicitly and move the “encrypted” part and also show the MIME types for encryption and compression like this:
>        Encryption, signature, compression before signing
>          - RFC2616/2045
>            - RFC5751 (application/pkcs7-mime; smime-type=enveloped-data) (everything below inside this part is encrypted)
>                - RFC1847 (multipart/signed)
>                  - RFC3274 (application/pkcs7-mime; smime-type=compressed-data) (everything below inside this part is compressed)
>                       - RFC1767/RFC3023 (application/EDIxxxx or /xml)
>                  - RFC5751 (application/pkcs7-signature)
>        Encryption, signature, compression after signing
>          - RFC2616/2045
>            - RFC5751 (application/pkcs7-mime; smime-type=enveloped-data) (everything below inside this part is encrypted)
>                - RFC3274 (application/pkcs7-mime; smime-type=compressed-data) (everything below inside this part is compressed)
>                    - RFC1847 (multipart/signed)
>                      - RFC1767/RFC3023 (application/EDIxxxx or /xml)
>                      - RFC5751 (application/pkcs7-signature)  I think 
> this is much clearer. What do you think? I’m also open to removing the “everything below...” texts if it is self-evident. Note that the original example mixed up before and after, if compression is applied before the signature, it must be inside the multipart message rather than outside it. That is fixed in my examples above.
>  (Debra: if the group agrees, I can rewrite all the examples in 4.2 along these lines).
>  -Erik
>  _______________________________________________
> Ediint mailing list -- [e-mail] To unsubscribe send an email to 
> [e-mail]  _______________________________________________
> Ediint mailing list -- [e-mail] To unsubscribe send an email to 
> [e-mail]


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