header it generates. If, on the other hand, an agent receives an RFC822/MIME
message containing 8bit material in a header, then the message is clearly
illegal in format and the agent is free to do with it as it pleases. Either way
this requirement doesn't apply so there is no issue to resolve. In fact by
making this statement you create an issue where none actually exists.
Right, my mistake. Bang head on wall ten times repeating: 'Even on 8bit
or binary transport, headers must be US-ASCII'. It's going better now.
Actually, it should be body part. Bodies refers only to the data, and that's
not where the encoding is specified.
Mmmm.... The content type gives the media type of the data in the body (this
is stated in the definition), and don't tell anything about the header. So
one should always speak about the 'type of a body', and this has finally
nothing to do with the 'dispute' about body parts/messages.
Incorrect. There is no header here so there is no need for an additional
blank line, and it is misleading to suggest that one is present.
I see. But maybe this would be easier to see if, in this paragraph:
(3) All of the header fields from the second and any
subsequent messages are discarded by the reassembly
process.
one would write 'any subsequent ENCLOSING...'. I had the (false) impression
that one should expect to find a header in each ENCLOSED thing. Not many
people are as stupid as I am, but who knows...
These rules are specific to messages. As such, the change to the word
entity isn't appropriate in this section.
I don't know... What can be splitted in fragments ? Only a message, or
any entity ? In the document (before any of the changes I suggested) both
words are used in the section, so I really can't see what the true
intention is.
/AF