* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #23 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

When to require (or not) the use of a normalizing (NFC) transcoder

Reported by: duerst@it.aoyama.ac.jp Owned by: addison@lab126.com
Priority: major Milestone:
Component: 3987bis Version:
Severity: - Keywords:
Cc:

Description

This is issue http://www.w3.org/International/iri-edit/#transcodeNFC-103 from the old issues list. This issue is originally from Björn Höhrmann (see http://lists.w3.org/Archives/Public/public-iri/2005Jun/0000.html). There is a proposal to change MUST to SHOULD (see http://lists.w3.org/Archives/Public/public-iri/2007Jul/0008.html).

Change History

comment:1 Changed 4 years ago by duerst@it.aoyama.ac.jp

Textual proposal from Addison and followup discussion at http://lists.w3.org/Archives/Public/public-iri/2010Sep/0039.html.

comment:2 Changed 4 years ago by addison@lab126.com

  • Owner set to addison@lab126.com

comment:3 Changed 4 years ago by duerst@it.aoyama.ac.jp

From editorial teleconf 2010-09-28:
(for reference only)

Ticket #23: When to reqire (or not) the use of a normalizing (NFC) transcoder

Martin: 3987 tried to make sure that string was in Unicode before processing *or* that non-Unicode string was normalized using NFC before transcoding

Addison: problem is that some transcoders aren't normalizing, right?

Martin: yes

Addison: no one wants to apply NFC "by fiat"

Larry: if implementations don't do this now, and they function, then there's no need for the requirement

Addison: currently things can be visually indistinguishable but are not identical on the wire

Larry: solution might be, don't create IRIs with unusual code point sequences

Addison: that's not really the issue -- transcoding is a source of denormalized IRIs

Martin: transcoding is a source of denormalization, but not the only one

Addison: problem is that Unicode has different code points that can represent the same graph

Larry: there might be a best practice here, but it's not necessarily to apply NFC

Addison: this is an implementation problem, not a spec problem

Larry: I think in general we have situations where the best we can do is describe what the problem is and why it is a problem, and then back off on normative recommendations that don't match what people are doing

ACTION ITEM: Addison to propose non-normative text that describes the problem in more detail

comment:5 Changed 4 years ago by duerst@it.aoyama.ac.jp

Addison's proposal applied at http://trac.tools.ietf.org/wg/iri/trac/changeset/22/ with slight tweak to align with previous paragraph.

comment:6 Changed 4 years ago by duerst@it.aoyama.ac.jp

  • Status changed from new to closed
  • Resolution set to fixed

The proposal from Addison was applied 5 months ago. It seems about time to close this issue.

comment:7 Changed 3 years ago by duerst@it.aoyama.ac.jp

  • Summary changed from When to reqire (or not) the use of a normalizing (NFC) transcoder to When to require (or not) the use of a normalizing (NFC) transcoder

fix typo in summary

Note: See TracTickets for help on using tickets.