Re: notes on mailing binary objects

[Einar Stefferud <Stef@xxxxxxxxxxx>]

I think we should quickly note several things.

1.  PEM-DEV@tis.com (subscription requests to pem-dev-request@tis.com)
    is a list related to an internet task force of some kind working
    on Privacy Enhanced Mail in the RFC822 connect, to be carried in
    the current RFC821 envelope without any mods to RFC821 or RFC822.
    PEM is deliberately designed to be independent of its means of
    carriage.

    PEM provides for public key encryption of keys and certificates
    and DES encryption of the body of messages.  I don't see any
    reason for RFC821 to be modified for the intended purposes, so I
    suggest that ietf-smtp should not take this task in its scope.

2.  If you are seeking a "secure-mail-transfer-system" then you will
    be designing yet another one to compete with the X.400(88)
    standard which does provide for security measures inside the P1
    (or MTA level envelope handling).

    I strongly suggest that trying to start now to design, implement,
    and deploy an entirely new start on such a system is a generous
    waste of time and effort.

3.  I note a considerable confusion in this list between extensions to
    RFC821 and extensions to RFC822.  I think this group should come
    to grips with this issue soon, and resolve what its scope really
    is.  For example, why should RCF821(ext) be concerned with the
    data types inside the body, as long as it has established that
    there is some 8bit data inside the body which must be protected
    and preserved in transfer.

    Is this task force concerned with RFC822 extensions, or is it
    limited to RFC821?  I suggest that it be limited to RFC821.

    Any structural changes to be made to the internal structure of the
    body of a message should be dealt with as an extension of RFC822
    (and its follow-on RFCs, of which there are several -- can someone
    identify all the related RFC822 RFCs, just for the record?).

    I know of RFC934 which defines an encapsulation format (with
    delimiter codes and bit-stuffing techniques) which is widely ( but
    not universally) used for forward messages and digests.  RFC1154
    provides a partially competing (with RFC934) scheme for placing
    multiple body parts inside a single "main" body part.  I recall
    that there are some other minor extension RFCs, but I forget their
    numbers.

Best...\Stef