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

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



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.makoto@xxxxxxxxxxxxxxx