IETF review of AS1

[Terry Harding <tharding@xxxxxxxxxxxxxxxxxxx>]

The AS1 documents Requirements for Inter-operable Internet EDI and
MIME-based Secure EDI are currently under review by IETF and they
have come back with some changes to the documents.  I would like
to get feedback from the list about one of these issues.

Feedback: My comments follow with <tnh>

5.4.1, last paragraph. This is the biggie. Saying it is OK to use
content-encoding in email even as an option just isn't acceptable. The
problem is one of interoperability: An unextended agent that receives
a message with, say, a content-encoding of gzip won't recognize the
field for what it is and will cheerfully decode the base64 expecting to
find text or whatever. Instead it will find garbage.
<tnh>This holds true regardless of the method used to indicate compressed
data. If we create a new Transfer-Encoding scheme or create a new header to
indicate that the payload is compressed, unless the receiving agent supports
the method in which compression was applied, it will received garbled data.

Unfortunately, the only way to add compression to email in a backwards
compatible way is to define new content-transfer-encodings. If this is a
real issue this is the mechanism that needs to be pursued.
<tnh> I don't believe this is a viable method as this header is used
extensively to indicate transfer encodings for smtp transfers. We would
be required to create a new encoding type that compressed as well as
converted the data into 7 bit ascii.

Note that it is fine to recommend use of content-encoding if the
transport is HTTP. Content-encoding is well-defined there and agents
are required to check for it and handle it.
<tnh> This will only apply to unsecured data, meaning the content-encoding
header is used as an http header and not within a mime bodypart. We require
the compression of the payload not the whole message..

<tnh>
So it looks like we have 3 choices,
1 - strongly suggest that we wish to use
the content-encoding header inside a mime bodypart
2 - create a new content-transfer-encoding method
3 - use one of the other acceptable headers to express compressed data.
     ex: Content-Description:
4 - add a name value pair to the content-type line
ex: Content-Type: application/xml; encoding=gzip
or  Content-Type: applicatoin/xml; conversion= gzip.

It is my preference to use a name value pair on the content-type line
if we can not use the content-encoding header.

Open for comments...

Terry Harding
Cyclone Commerce