In the Message Bodies document:
Section 3, paragraph 4 uses the term "body part" not in conformance
with the definition in section 4.4. Suggest using the term "objects".
Actually, the conformance is pretty close. The comments made in this section
apply to X.400, and X.400 really does carry around things that correspond to
MIME body parts for the most part.
X.400 has a much easier time of it since messages contain multiple body parts
and only one particular type of body can contain, among other things, a
message. There is no aggregating structure that's equivalent to a MIME
multipart in X.400, other than the fact that every message is equivalent for
aggregation purposes to multipart/mixed.
There are some gaps, however. In particular, not all X.400 bodies can carry
around the equivalent of the various content- headers (only FTBPs can). So
agree that a change to the generic term "objects" is in order.
Section 3, paragraph 5, subsection (3) does not mention that the c-t-e
also specifies the domain of the result.
Fixed.
Section 3, paragraph 6, the sentence "In particular, all of these
header fields can incclude RFC 822 comments...". This is incorrect,
the Content-Description header field is an unstructured header field
and thus does not permit free insertion of linear white space and
comments. Also, other unstructured content header fields may be
defined in the future.
I'll note in the prose that content-disposition is an exception. The prose
already states that it only applies to fields "defined in this document", so
the fact that future documents may define additional fields is not relevant.
Section 4 repeatedly states that the definitions of the terms are
defined "in this document". They are actually definitions for all
MIME documents.
I had already gone through all of the "this document" references and
corrected the ones that needed correcting.
Section 4.2, remove the word "table-based". unicode-1.1-utf-7 is a
legitimate charset which is not table-based, at least for any
meaningful definition of "table-based".
Having implemented unicode-1.1-utf-7 mappings, I somewhat disagree, but
don't see that table-based helps much.
I think we should replace the term "character set" with "charset",
to reduce the conflict with what other communities use the term
"character set" for. Another possibility would be to use the term
"character encoding".
This point has already been raised. I was willing to make the change, but it
was shot down in flames by the area directors. The current terminology, whether
it is consistent or not with usage in other venues, stays.
The term "entity" is used in various places with meaning not in
conformance with the definition in 4.5. For example, the document
talks about "registration procedures for MIME-related entities"
I hate to say it, but I disagree with Ned about the new definition of
"body part". The term "body part" is used several places, especially
in section 7.1 of the media types document, to refer exclusively to
the parts of a multipart. Only one use of the term "body part" is
intended to include messages, I mention it later as needing
correction.
My conclusion is just the opposite. All of the uses of body part are
consistent with the current definition as far as I can tell. I have checked
them all at least half a dozen times now.
I'm getting really tired of arguing about this particular point, so I'm
elevating this one to personal showstopper status. The current definition is
going to stay as long as I'm editor of the document, period.
If you want to address particular uses of the term "body part" you are going to
have to do them on a case by case basis, and I'll warn you right now that I
will be VERY reluctant to change any of them.
Section 4.10, replace the word "text" with "data". Lines are not
necessarily textual.
True enough. Changed.
Section 5, the grammar nonterminal MIME-part-headers is unreferenced.
It does not permit "fields", especially "X-" headers; which are
permitted by section 7.1 of the media types document.
They are permitted but they have no defined meaning. I think it is important
to note this in the BNF, so I have changed the MIME-part-headers BNF to
read as follows:
MIME-part-headers := [ content CRLF ]
[ encoding CRLF ]
[ id CRLF ]
[ description CRLF ]
*( mime-extension-field CRLF )
fields
; Any field not beginning with
; "content-" can have no defined
; meaning and should be ignored.
; The ordering of the header
; fields implied by this BNF
; definition should be ignored
The intent was always to tie this definition into the body-part BNF, but the
change slipped through the cracks. I've therefore changed the BNF for body-part
to read as follows:
body-part := MIME-part-headers *( CRLF *text )
; Lines in a body-part must not start
; with the specified dash-boundary and
; the delimiter must not appear anywhere
; in the body part. Note that the
; semantics of a body-part differ from
; the semantics of a message, as
; described in the text.>
Section 7.1, grammar nonterminal "parameter" needs a comment stating
that matching of attribute is case-insensitive
I think its better to put this note on the attribute nonterminal.
The documents have uses of the terms "8-bit" and "7-bit" sprinkled
throughout, these should be "8bit" and "7bit".
The original intent was to keep the abstration of 7-bit and 8-bit separate from
the CTEs 7bit and 8bit, but I no longer see any justification for this.
I've gone ahead and made the usage consistent everywhere except in the
bibliography, where the terms come from other standards documents.
Section 8.7, the senetence "Since the hyphen character ("-") is
represented as itself in" should replace "is" with "may be".
Changed.
In the media types document:
Section 7.1 paragraph 4, "in which all parts actually are messages"
replace "all" with "most".
Changed.
Section 7.2.1, paragraph 2, the term "body parts" should be
"entities", to be consistent with similar wording in section 7.1.
I actually think it makes more sense to talk about encodings for
bodies rather than encodings for entities or body parts.
Disagree. It doesn't necessarily make sense to restrict the CTE of messages in
general, since not all messages are MIME messages. It is entirely possible for
there to be a non-MIME usage of a content-transfer-encoding header where a
message ends up with some other CTE. (I would oppose any attempt to specify
such usage, but that's beside the point.)
The use of the term "body part" here stays.
In the registration procedures document:
There should be aliases for the ietf-types and ietf-charsets lists
established at ISI, forwarding mail to the actual site that runs each
particular list. The aliases should be what are published in the
document.
This has already been discussed. It will be up to the RFC editor to establish
these aliases and make the necessary changes to MIME-REG. I already have a note
in place to make sure that the RFC Editor is tasked with making this change
prior to publication. If it happens, that's great, and if there's a slip-up
at least the addresses work for the time being.
I am not willing to put aliases in these documents that don't work right now
and/or whose existance isn't guaranteed in the future. And since the number and
nature of these aliases isn't settled until the documents are truly finalized,
I don't think it makes sense for the RFC Editor to act on this right now. (If
past experience is any indicator, things get screwed up more often by premature
implementation of something other than what the final specification says than
by any other means.)
Section 7.1.4 should use the "7bit data", "8bit data", and "binary
data" terms defined in the message bodies document.
Changed.
In the conformance document:
Requirement (2) should include a statement that readers must recognize
the "7bit", "8bit", and "binary" transfer encodings.
Agreed and added.
I had mentioned to Ned at the last IETF that there should be a
requirement for readers to treat bodies that have an unrecognized
Content-Transfer-Encoding as if the Content-Type were
application/octet-stream, regardless of whether or not the reader
recognizes the value of the Content-Type header. This requirement
should be added, probably as item (6), to the conformance document and
should be mentioned somewhere in section 8 of the message bodies
document (either 8.3 or 8.4).
Agreed and added. (I put this in with the rest of the CTE material in the
conformance section rather than create a new item at the end of the list.)