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 Thursday, 3 August 2000 02:20:49 UTC