I understand now and am happy to hear some clarifications will be considered.
At 11:25 AM 12/11/95, Ned Freed wrote:
....
Appendix G only describes the encoding process and not the decoding process
where this becomes an issue.
First of all, use of the term "encoding" is inappropriate here. The process
may include encoding as one of its steps, but it isn't the only thing that
is done.
I just got the term "encoding" from the title of Appendix G in 1521 is all.
Second, to use your terminology, the "decoding" process is simply the inverse
of the "encoding" process. What could be simpler?
I have no problem with stating this explicitly, and I have added prose
along these lines to the current MIME drafts.
Yes, that would make it clear especially knowing that canonicalization is
always associated with a particular content type.
For example, the description of
content-type text doesn't say that its canonical representation has CRLF
line endings.
I beg to differ. This is stated, not once but several times. Quoting
directly from MIME part 2:
The canonical form of any MIME text type MUST represent a line break as
a CRLF
sequence. Similarly, any occurrence of CRLF in text MUST represent a line
break. Use of CR and LF outside of line break sequences is also forbidden.
I don't think this could be any clearer.
Me neither. This is partially my fault as I was reading 1521 which doesn't
have this text. I knew there were more recent drafts, but hadn't saved all
the 822 extensions traffic to be able to check them.
So, I do think something needs to be clarified (aside from my own messages).
Well, I agree to the extent that what you call "decoding" needs to be
called out as the inverse of "encoding". I always thought this was
obvious, but a clear statement of it could not hurt.
But that's as far as I go. Much of what you see as clarification I see as
obscuring the issues. The bottom line is that MIME plus the collectiong of
defined types presents a single, consistent format for material. Extensive
discussion of the various shortcuts that are used in dealing with such
material
may be both interesting and useful, but has no place in the standard itself.
Yes, the important thing is making it clear that each content-type may have
a canonical format and the canonical format is associated only with the
content-type. It might be worth clarifying that line ending
canonicalization is something that is common to a lot of formats, but is
still strictly associated with only certain content types. Most of my
comments were for the sake of discussion, and wasn't expecting anything to
do with current UNIX e-mail practice to go into the standard.
LL