Your comments on the Character Model [C184]

Dear Chris and TAG,

Many thanks for your comments on the 2nd Last Call version of the Character
Model for the World Wide Web v1.0 [1].  We appreciate the interest you have
taken in this specification.

You can see the comments you submitted, grouped together, at 
http://www.w3.org/International/Group/2002/charmod-lc/SortByOriginator.html#
C115
(You can jump to a specific comment in the table by adding its ID to the end
of the URI.)

PLEASE REVIEW the decisions for the following comment and reply to us within
the next two weeks at mailto:www-i18n-comments@w3.org (copying
w3c-i18n-ig@w3.org) to say whether you are satisfied with the decision
taken. 
        C184

Information relating to these comments is included below.

You can find the latest version of the Character Model at
http://www.w3.org/International/Group/charmod-edit/ . 

Best regards,
Richard Ishida, for the I18N WG






DECISIONS REQUIRING A RESPONSE
==============================

C184	Na	Na	C	Chris Lilley
	TAG
	P	MD	3.6.2	Character encoding identification

    *

      Comment (received 2002-05-27) -- Comments on charmod from Chris
http://lists.w3.org/Archives/Public/www-tag/2002May/0164.html

      'Because of the layered Web architecture (e.g. formats used over
protocols), there may be multiple and at times conflicting information about
character encoding. [S] Specifications MUST define conflict-resolution
mechanisms (e.g. priorities) for cases where there is multiple or
conflicting information about character encoding.'

      Yes. Better though to not define such layering; the XML MIME RFC
messed this up by allowing the charset and the xml encoding declaration to
differ and for the former to take precedence; this requires 'save as' to
rewrite the XML otherwise it is no longer well formed.... better to require
any transcoders to leave XML alone or to know how to rewrite the encoding
declaration if they change the encoding.
    *

      Decision: Not applicable.
    *

      Rationale: We decided to reject this comment, in the sense that we are
not dealing with this issue in the current version. However, we will note
this issue for an eventual future version of the document.

      We would like to point out that we do not introduce layering, we just
point out that it exists. On the specific point of RFC 3023, we can agree
that some adjustments may be needed, but we think that this is for the IETF
process to decide this. Going as far as disallowing a charset parameter in a
protocol does not seem appropriate, because it would restrict implementation
and deployment too much. In general, saying something like "don't allow too
many ways of specifying the character encoding" seems like a good idea, but
it is too general to be helpful for actual specification designers, and
providing more detailed advice and examples seems difficult at this point.




USEFUL LINKS
==============
[1] The version of CharMod you commented on: 
http://www.w3.org/TR/2002/WD-charmod-20020430/
[2] Latest editor's version (still being edited): 
http://www.w3.org/International/Group/charmod-edit/
[3] Last Call comments table, sorted by ID: 
http://www.w3.org/International/Group/2002/charmod-lc/

Received on Friday, 23 January 2004 07:49:29 UTC