The specification of whether those tools require such conversion doesn't
belong in the body part header; it belongs in the mailcap or whatever file is
used to specify presentation.
We use a different non-mailcap file for this information, but the idea here is
correct.
The conversion between CRLF and local line convention is just one example of
the conversion between canonical form and local form. Fortunately, for most
content-types on most machines there is no difference between the canonical
form and local form, but the model applies anyway.
Some of us live in a more complex world where the canonical form and local form
often differ. In fact in some cases the local form of a type depends on the
specific application that will process the information rather than the
platform. File servers are one source of such issues, but there are others. I
run into this last case on a fairly regular basis.
Appendix G only describes the encoding process and not the decoding process
where this becomes an issue. If canonicalization is implied by the content
type, it is not stated anywhere. For example, the description of
content-type text doesn't say that its canonical representation has CRLF
line endings. Right now there are differences in implementations. Munpack
converts CRLF for type text/* only, and Pine converts for type text/* and
messages/rfc822. It seems to me some text that describes the decoding
process and a statement that says text/* always should have CRLF line
ending would be a good thing.
Yes, this is a problem, and it needs to be fixed. Every content-type
definition should clearly define the canonical form.
I don't think this is a problem any more. See the text I quoted in my
previous response. It is quite clear on what constitutes the canonical
form for text.
I agree with this also. The problem is that it's difficult to convey the
notion of the encoding model. Too little prose and the subtlety gets lost;
too much prose and the reader is overwhelmed.
Exactly. The minute you start introducing the notion of what operations
are likely to be needed you necessarily introduce what local forms
are in use. But this is only acceptable up to a point -- a vast
variety of local forms exist in practice, the issues are incredibly
subtle, and talking about the specifics of any one platform are likely
to confuse the people on other platforms where the issues are different
but will be seen to be the same.
Ned