Dan,
Looks good. A few comments.
Thank you for your attention and comments.
Omitting the charset parameter is NOT RECOMMENDED for text/xml. For
example, even if the contents of the XML MIME entity are UTF-16 or
UTF-8, or the XML MIME entity has an explicit encoding declaration,
XML and MIME processors must assume the charset is "us-ascii".
Could you please explain why the MIME charset declaration must take
precedence over an explicit encoding declaration.
RFC 2616 (Hypertext Transfer Protocol) is a draft standard of IETF. It clearly
says that the charset parameter is authoritative. Probably, this I-D should
explicitly reference to RFC 2616.
3.4.1 Missing Charset
Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean "recipient should guess."
Senders wishing to defeat this behavior MAY include a charset
parameter even when the charset is ISO-8859-1 and SHOULD do so when
it is known that it will not confuse the recipient.
Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that have
a provision to "guess" a charset MUST use the charset from the
content-type field if they support that charset, rather than the
recipient's preference, when initially displaying a document. See
section 3.7.1.
You wrote:
Also, since you use must, you might consider referencing RFC 2119.
I believe that it is already referenced.
Ordinal
numbering of footnotes provides no additional useful information, while
using [RDF] instead of [14] makes it clear (especially at second glance)
what is being referenced.
This I-D is originally written in XML, and the DTD is specified by
RFC 2629. The footnote numbers are generated by the conversion software.
You might consider internally referencing the text (e.g., the Encoding
Considerations) from text/xml into application/xml rather than repeating it.
That way, it would be completely clear what the divergence was rather than
having to compare the text blocks.
This part of the specification is borrowed from RFC 2376 as is. Probably,
RFC 2376 should have been written in the manner you suggested. But I do
not think I should try to rewrite it now. Such rewritting may cause
inconsistencies.
Would it make sense to add a note to application/xml-dtd explaining that
DTDs are not valid XML documents?
Yes, it certainly does. I will add such a note in the next version.
ESMTP does not equal 8-bit clean. Every time you say "(e.g., ESMTP,
8BITMIME, or NNTP)" I think you mean to say (e.g., 8BITMIME ESMTP or NNTP).
Yes, you are very right. RFC 2376 has the same problem. ;-) I will
fix this in the next version.
Cheers,
Makoto
Fuji Xerox Information Systems
Tel: +81-44-812-7230 Fax: +81-44-812-7231
E-mail: murata(_dot_)makoto(_at_)fujixerox(_dot_)co(_dot_)jp