Re: FW: draft-ietf-ediint-as2-01.txt for review

["Dale Moberg" <Dale_Moberg@xxxxxxxxxxxx>]

>I interpreted the draft as saying that the To:, From:, and Message-ID:
>headers were supposed to be sent as extension headers along with the
>HTTP headers.

The current text probably needs some clarification but the "TO" etc headers
are added as extension headers. They may also be repeated in the
message body; maybe that needs to be suggested explicitly.

>> Note that existing CGI processing does not pass the extension headers to
the
>> processing application. Thus, the content-type: message/rfc822 works,
and
>> merged headers won't work with existing http/cgi servers. [This was Carl
Hage's
point I think.]
>The Java Servlet API also doesn't make it easy to get extension
>headers.  I believe it's possible, but very awkward.  You probably
>could enumerate the headers with getHeaderNames() and look up each
>header's value with getHeader(name), but I bailed out and didn't try
[This was John Interrante's comment.]
I wanted to avoid getting too much into implementation details, but
consider what
the CGI environment variable specification says:

http://hoohoo.ncsa.uiuc.edu/cgi/env.html

"In addition to these, the header lines received from the client, if any,
are placed into the environment with the prefix
HTTP_ followed by the header name. Any - characters in the header
name are changed to _ characters. The server
may exclude any headers which it has already processed,
such as Authorization, Content-type, and Content-length. If
necessary, the server may choose to exclude any or all of these
headers if including them would exceed any system
environment limits. "

The servers I checked did make the extension headers available
to the responding application thread/process.
There was not much problem in doing so, although some makers of
perl dlls at one time required you to "know" which headers
are expected and to "ask" for them (this was the Active State dll).
I originally was conservative on the number
of extension headers specified because of the statement that a server
was allowed to omit them if they exceeded
environment limits. Because of previous discussionon the first draft,
I added on more of the SMTP headers to the HTTP header
fields.

There is no harm in adding these headers to the message body,
but it is not really generally true that
existing CGI processing fails to pass extension headers in
environment variables such as "HTTP_TO" and so on.
There may be some implementations that prefer to access the
information in this form. So it seems to be that the choices are at least:

-header information must be in both extension and message body headers
-header information must be in extension and may be in message body headers
-header information must be in message body headers and may be in extension
headers
-header information must be in at least one of the places

 (IMO, there should be one place it must be and the other place it may be.
The header information here being referred to is, of course, the
information
needed for ediint processing ...)

Any other options?

>I also like the idea of using the Content-Encoding: gzip header to
>compress medium to large EDI messages.  Size really matters a lot to
>throughput.
This can be explicitly mentioned if there is a consensus for doing so.