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

["Dale Moberg" <Dale_Moberg@xxxxxxxxxxxx>]

>I didn't realize that the RFC822/2045 headers were supposed to go in
>the message body of the HTTP request.  I had the impression (Carl Hage
>probably did, too) that the RFC822/2045 headers were supposed to go
>ONLY in the headers of the HTTP request itself, not in the body as
>well.

No, the way the current draft reads, all the SMTP RFC 822 headers
are extended headers and the message body is just the MIME
part of the original message. My reply was concerning something else
that could be done. Currently the only content types are the ones from
ediint as1 and not the new "tunnel" type, message/rfc822.

So I agree when you add:


 >t makes a world of
>difference to the Content-Type header.  In one interpretation, the
> header (in the HTTP request) can only be:
>Content-Type: message/rfc822
>In the other interpretation (where the headers are optional in the
>body of the HTTP request), the header could be any of these:
>
>Content-Type: message/rfc822
>Content-Type: application/EDIxxxx
>Content-Type: multipart/signed
>Content-Type: application/pkcs7-mime
>Content-Type: application/x-pkcs7-mime
>I suppose I could live with "one place it must be and the other place
i>t may be" since I could check the Content-Type header and execute
>different code depending on what it says, but it'd make the code more
>complicated!

The only thing we have in the draft so far is for the cases of content
types other than message/rfc822.

It is possible some applications will not read in all the
stream and then process the data, and I don't think that
this particular implementation concern should decide
adding on the message/rfc822 type.

I guess what I meant is that you _could_ have the headers
other than as extended headers. And this was the issue
that Carl was raising. But the reason he provided (that the
extended headers are unavailable to processes) seems
not to be decisive. The extended headers seemed to be
a good place to put headers which were not MIME headers,
and I still think that is the case.

What Carl seems to be thinking about is almost using
http as a tunnel for an email message. And that could be done,
That is what I meant to indicate as an issue for discussion.
It is not what we currently have. I don't really see tunnels as
having decisive advantages or disadvantages compared
to the current draft unless getting at extended headers are
really a problem.

The model previously  was more that the server is like inetd and listens
and then starts up the appropriate process and hands off the IO to
that process. The payload is just the MIME part (the message body) and
not the message as a whole.  But I guess the tunnel format could fit
into  this inetd  picture also.