[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Announcement of draft-murata-xml-01.txt

Looks good.  A few 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.  Specifically, I'm
concerned about cases where users author XML documents which internally
specify UTF-8, but then upload them to HTTP servers that automatically (and
incorrectly) tag them as US-ASCII or as nothing (which has the same effect).
Why would the MIME charset declaration ever be more canonical or more
correct than the internal one?  I would suggest perhaps adding some language
to explain this decision.

Also, since you use must, you might consider referencing RFC 2119.  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.

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.

Would it make sense to add a note to application/xml-dtd explaining that
DTDs are not valid XML documents?

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).

		- dan
Daniel Kohn <mailto:dan@xxxxxxxxxxx>
tel:+1-425-519-7968  fax:+1-425-602-6223

-----Original Message-----
From: MURATA Makoto [mailto:murata.makoto@xxxxxxxxxxxxxxx]
Sent: Wednesday, 1999-11-17 03:20
To: ietf-xml-mime@xxxxxxx
Subject: Announcement of draft-murata-xml-01.txt

Simon St. Laurent and I co-authored an I-D for XML media types.  It 
is available at:


On the basis of discussion in this ML (most notably Ned's comments),
this version shows when text/xml is more appropriate than application/xml 
and vice versa.  Non-XPointer fragment identifiers for XML vocabularies 
like SVG and SMIL requires further discussion.

Incidentally, the XSLT recommendation is published from W3C today.  It is 
available at:


Although we have agreed that fragments do not have media types, "2.7
Stylesheets" of this recommendation uses "text/xml" for fragments.  Since
recommendation of W3C, namely "Associating stylesheets with XML documents", 
already mandates the pseudo attribute "type" for stylesheet-linking PIs, 
XSLT had to specify something.  Comments?


Fuji Xerox Information Systems
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: murata.makoto@xxxxxxxxxxxxxxx