iri issue tracker
2012-03-02 01:12:38 UTC
#114: priority of UTF-8 => %xx encoding in comparison ladder
From "iri-comparison" originally "Should we insist that percent-hex
encoding equivalence of non-reserved characters
MUST be always used if there is any equivalence at all?
The issue is that since we're initially doing %xx percent hex encoding for
characters, for all forms, that it should be the baseline for any kind of
equivalence that isn't exact match.
So the "percent-encoding normalization" should be higher priority than
"case normalization" (i.e., you should not do case equivalence without
percent equivalence.)
--
------------------------+-----------------------------------------
Reporter: masinter@… | Owner: draft-ietf-iri-comparison@…
Type: defect | Status: new
Priority: major | Milestone:
Component: comparison | Version:
Severity: - | Keywords:
------------------------+-----------------------------------------
Ticket URL: <http://trac.tools.ietf.org/wg/iri/trac/ticket/114>
iri <http://tools.ietf.org/wg/iri/>
From "iri-comparison" originally "Should we insist that percent-hex
encoding equivalence of non-reserved characters
MUST be always used if there is any equivalence at all?
The issue is that since we're initially doing %xx percent hex encoding for
characters, for all forms, that it should be the baseline for any kind of
equivalence that isn't exact match.
So the "percent-encoding normalization" should be higher priority than
"case normalization" (i.e., you should not do case equivalence without
percent equivalence.)
--
------------------------+-----------------------------------------
Reporter: masinter@… | Owner: draft-ietf-iri-comparison@…
Type: defect | Status: new
Priority: major | Milestone:
Component: comparison | Version:
Severity: - | Keywords:
------------------------+-----------------------------------------
Ticket URL: <http://trac.tools.ietf.org/wg/iri/trac/ticket/114>
iri <http://tools.ietf.org/wg/iri/>