[Top] [All Lists]

A compromise proposal in the making (Was: My Greatest Fear)

1991-08-26 17:34:23
John Klensin writes:

   I believe that I'm in agreement with this, but...

Are you in agreement with the stronger version? I don't think so.

  Yes, I am in agreement with the stronger version.  Why?  Because my 
analysis of the cases in which I think that nested encoding would be 
very useful has gradually caused me to conclude (again, I might add) 
that there aren't any.

Well, if you'll pardon my saying so, this is fan-f***ing-tastic!

This leads me to offer a compromise proposal. I'm going to spell it out now,
we can discuss the details, and then I'd like to get a vote on it.

In brief, these are the points of my proposal:

(1) Nested encodings will be banned completely in RFC-XXXX. Specifically, this
    means that a Content-TransferEncoding of either base64 or quoted-printable
    is illegal on bodyparts of type multipart, multipart/mixed,
    multipart/digest, message, and message/partial.

    Encoding specifications may possibly be needed/useful on message/pem parts
    (although they may appear at a lower level); this is an item for a later
    day and probably a different WG.

(2) A Content-TransferEncoding _can_ be specified on multipart, multipart/mixed,
    multipart/digest, message, and message/partial bodyparts. If specified,
    it identifies the "most general" encoding used in the bodypart. There are
    three possibilities:

    (1) binary    <-- most general
    (2) 8bit
    (3) 7bit      <-- least general

    For example, if 7bit is specified, it means that the most general
    encoding used by any subpart of this bodypart is 7bit. 8bit means that
    subparts may be either 7bit or 8bit, and binary means that the subparts
    may be binary, 8bit, or 7bit.

    Note that no provisions for transporting binary have yet been defined. This
    stuff is only a placeholder at present; it would be illegal in either
    old-SMTP or the current draft extended-SMTP.

    This information is useful for determining what sort of message is at
    hand without having to scan it. Should this information be mandatory?
    Should we get rid of this idea completely? Comments?

(3) A new header will be defined: TransferEncoding-Conversion:. It can have
    the values "prohibited" or "allowed". This header only has meaning in
    the outermost set of headers -- if present, it controls whether or not
    an agent is allowed to change the Content-TransportEncoding for any
    part or parts of the message to make it possible for the message to
    pass over "narrower" channels (like old SMTP).

(4) The SMTP extensions document should specifically allow an MTA faced with the
    need to convert a message from 8bit to 7bit to do one of the following:

    (a) Bounce the message, either without return-of-contents or with the
        contents converted using the procedure below. This is mandatory if
        the TransferEncoding-Conversion header specifies "prohibited".

    (b) Convert the message using the procedure below. This may only be done
        is the TransferEncoding-Conversion header is either missing or
        specifies "permitted".

    No other actions are permitted. The conversion procedure is, roughly:

      Scan the message, paying attention only to the structure and to the
      Content-TransferEncoding headers that appear. A
      Content-TransferEncoding header that specifies 8bit should be changed
      to quoted-printable, and the bodyparts it applies to should be
      encoded accordingly. (Future extension: binary bodyparts should be
      converted to base64, and encoded appropriately.)

      Errors, such as the specification of 7bit encoding on what turns out
      to be an 8bit bodypart, should cause the message to bounce immediately.

    This needs to be tightened up and formalized, but all I'm interested in
    now is getting the meaning clear enough to see if its is agreeable to
    everyone. The writing of the formal specification can come later.

Comments on this are welcome. 


<Prev in Thread] Current Thread [Next in Thread>