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

Re: Some text that may be useful for the update of RFC 2376




MURATA Makoto wrote:
> 
> In message "Re: Some text that may be useful for the update of RFC 2376",
> Chris Lilley wrote...
> 
>  >> - XML sent (e.g. mail, http) as text/xml (or equivalent, e.g. text/vnd.wap.wml):
>  >
>  >as text/"anything" in other words
> 
> I think that RFC 2046 covers text/* in general.  RFC 2376 cannot
> change the default of HTTP (i.e., 8859-1).  The IAB allowed
> RFC 2376 to change the default for text/xml only.

That was what I was suggesting, changing it for text/xml only.

> 
>  >>   - Charset parameter is strongly recommended
>  >
>  >Charset parameter is required if the charset is not UTF-8 or UTF-16
> 
> Even when the charset is UTF-8 or UTF-16, the parameter is required.
> Otherwise, we will be inconsitent with RFC 2046.
> 
>  >>   - If no charset parameter, default is ASCII. The default of iso-8859-1 in
>  >>     HTTP is explicitly overridden in the specification of the charset
>  >>     parameter in section 3.1 "Text/xml Registration" of RFC 2376
>  >>     (http://www.ietf.org/rfc/rfc2376.txt)
>  >
>  >The charset (not default, but THE charset) is UTF-16 (if BOM) or UTF-8 (if
>  >no BOM) and the "default" of iso-8859-1 in HTTP and US-ASCII in mail is
>  >explicitly overridden ...
> 
> This conflicts with RFC 2046.

Only if adopted as ageneral rule for all text/*, which I was not
suggesting. I was suggesting, instead, that it be for text/xml and
text/*-xml


> 
>  >> - XML sent as application/xml (or equivalent):
>  >>   - Charset parameter is strongly recommended, and if present,
>  >>     it takes precedence.
>  >
>  >Charset parameter is *disallowed*.
> 
> I do not agree.
> 
> You might think that we can avoid bad WWW servers by this change.  But
> we cannnot.  We have to handle a collection of XML, XSL, CSS, VBScript,
> JavaScript, etc. 

Perhaps, but in that case ietf-*XML*-mime would not be the place to propose
such a cange.

> We need a solution that works for every format.
> Otherwise, data will corrupt.

I would add, we need a solutionthat works for every transport, including
'file'. Otherwise, data will become corrupt.

--
Chris