Re: Followup on I18N Last Call comments and disposition

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?
_

Canonicalization algorithms take two implicit parameter when they appear as
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.)

_

 ...
 >>  >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 Wednesday, 2 August 2000 15:48:22 UTC