Re: Followup on I18N Last Call comments and disposition

Hello Joseph,

Just some very small comments, otherwise it looks good to me:

At 00/08/02 15:48 -0400, Joseph M. Reagle Jr. wrote:
>At 17:18 8/1/2000 +0900, Martin J. Duerst wrote:
>  >>Propose: We RECOMMEND that signature applications create XML content
>  >>/+(Signature elements and their descendents/content)+/ in Normalized Form
>C
>  >>[NFC] and check that any XML being consumed is in that form as well (if
>not,
>  >>signatures may consequently fail to validate).
>  >
>  >That's okay. The changes I would additionally propose for that whole
>  >paragraph is to move the sentences about data type normalization to the end
>  >(so that character encoding and character normalization go together),
>  >and to not say anything about Canonical XML at this point, to avoid
>  >update problems (on the other hand, Canonical XML HAS to say that
>  >there is no BOM at the start).
>
>I left the note about canonicalization (the references are to dated specs)
>and moved the data normalization to the end of the paragraph.
>
>  >>proposed text in 6.5:
>  >Very good base to work with, but a few proposals:
>  >- 'algorithms takes': remove one s.
>  >- There should be a period at the end :-).
>  >- The (Note) should come later, probably at the end of the paragraph.
>  >- Change 'media formats' to media types, it's more consistent.
>
>
>ok*4
>
>  >- The (currently) last sentence is the wrong way round. It should read
>  >   e.g. 'Canonicalization to NFC [UTR #15] SHOULD be performed as part of
>  >   transcoding from a non-Unicode encoding to Unicode.'
>
>Oops, right. Fixed.
>
>  >- Your argument about SHOULD above is okay, but for the algorithms
>  >   that are required or recommended, it should be a MUST. I would try
>  >   to reword so that the where-clause of the previous sentence
>  >   applies, and change from SHOULD to MUST. Other algorithms can
>  >   do whatever they want, but I guess a MUST for the req... ones
>  >   will give them enough of a hint to do the same thing unless
>  >   they have very specific reasons not to do so.
>
>Ok. I achieved the symmetry you wanted below. However, it doesn't make that
>much sense to me in that we define the REQUIRED algorithms. Consequently,
>shouldn't we just say NFC and UTF8/UTF16 are RECOMMENDED for all , and
>define 6.5.1 and 6.5.2 apporpiately (MANDATORY support/creation of/for those
>formats?) Or is it easier to keep it in the general section?

Well, whatever you like.


>_
>
>Canonicalization algorithms take two implicit parameter when they appear as
                                                         ^s

>a CanonicalizationMethod within the SignedInfo element: the content and its
>charset. The charset is derived according to the rules of the transport
>protocols and media types (e.g, RFC2376 [XML-MT] defines the media types for
>XML). This information is necessary to correctly sign and verify documents
>and often requires careful server side configuration.
>
>Various canonicalization algorithms require conversion to [UTF-8].Where any
>such algorithm is REQUIRED or RECOMMENDED by this specification the
>algorithm MUST understand at least [UTF-8] and [UTF-16] as input encodings.
>Knowledge of other encodings is OPTIONAL.
>
>Various canonicalization algorithms transcode from a non-Unicode encoding to
>Unicode. Where any such algorithm is REQUIRED or RECOMMENDED by this
>specification the algorithm MUST perform normalization [NFC]. Otherwise,
>normalization is RECOMMENDED. (Note, there can be ambiguities in converting
>existing charsets to Unicode, for an example see the XML Japanese Profile
>[XML-Japanese] NOTE.)

In the above paragraph, I guess it would be best to change 'normalization'
to something like 'text normalization' or so, two times.

Regards,   Martin.



>_
>
>  ...
>  >>  >See http://www.w3.org/TR/xmlbase#IDwNAq1.
>  >>  >Please note that 'crosshatch' should be changed to 'number sign',
>  >>  >because this is the official ISO 10646/Unicode name.
>  >>
>  >>Ok, text in the Reference section will say:
>  ...
>  >Great, but I suggest you take out the reference to [XPtr].
>  >XPtr is not the definitive reference for this, it's just another
>  >case of specifying the same thing.
>
>Ok.
>
>_________________________________________________________
>Joseph Reagle Jr.
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Friday, 11 August 2000 01:57:35 UTC