Re: [apps-discuss] Thoughts on text/* encoding defaults

[Dzonatas Sol <[e-mail]>]

On 06/06/2011 05:42 AM, Julian Reschke wrote:
>
> Left to do:
>
> a) Revise RFC 2046; allow text/* types that carry encoding information 
> inline to do the expected thing (overriding the US-ASCII default); 
> warn against doing so in new registrations (recommend to only support 
> UTF-8, and require to always explicitly include the charset parameter, 
> such as text/vcard is going to do it?)
>
> b) Revise RFC 3023 to delegate text/xml charset defaults to revision 
> of 2046?
>

This has probably been said before by someone else, yet there is some 
reason about the above action which makes me concerned when we don't 
first assume use of "us-ascii" that there may be loss of compatibility 
with 7bit communications (and compression algorithms), especially in 
hardware that doesn't require updates based on known standards. I know 
UTF-8 includes the literals, yet if we strip the 8th bit on 
unicoded-to-ascii escape sequences then is the media content still 
compatible (even size wise before and after compression)? Or would this 
cause unknown error correction where UTF-8 is an explicit replacement of 
"us-ascii". I think that there is the significant point to 7bit being 
"must" by that 7bit mode being specifically implied by "ascii" because 
the 8th bit in UTF-8 is not "human readable" in regards to plain XML. To 
only support UTF-8 means one more bit is being added to the 7bit standard.

I do recognize you want to resolve the conflict for further support with 
ISO & I18N. I think what you want why some tried to progress "code 
pages" in context.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant