Subject: [urn] 2141bis questions - (3) Section 4.1 "normalization" comment

From: John C Klensin <[email-masked]>
Date: Tue, 23 Dec 2014 12:31:56 -0500

Hi.

Section 4.1 ("Procedure"), third paragraph, talks about
"applying case normalization".  There is no such thing in
Unicode even though 3986 has a section of that title .   It
would be an editorial issue and easily fixed if I was sure what
the WG intended, but I'm not.  It isn't clear whether Section
6.2.2.1 of RFC 3986 is included or excluded by a "syntax only"
policy.  Even if it is included, it generically applies to the
two characters that follow "%" in percent-encoding, the scheme
name, and the host (the latter being irrelevant for URNs).
Other components are specified on a per-scheme basis.

Independent of the terminology it uses, the text in 3986
specifies that the characters that follow "%" in
percent-encoding must be converted to upper case and that scheme
names (and the host component) must be converted to lower case.
The text in the current version of 2141bis says (construct 4)
that the p-component is to have "case normalization" applied,
but doesn't specify upper case, lower case, or case folding.
We either need to get p-components out of that list, making them
case-sensitive, or need to choose one of the three.   Note that,
because of situations like "what happens with accent marks when
converting to upper case" (and its opposite of an accent-free
upper case character potentially mapping to two or more lower
case characters), arguments that position-dependent characters
in Arabic or other scripts should really be treated as case
variations, etc., this is not a trivial decision.  If we care
about consistency with the reasoning of IDNA and probably
PRECIS, we should probably (but only probably) preserve
case-sensitivity as much as possible.

   john

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 23 Dec 2014 11:48:05 -0700

On 12/23/14, 10:31 AM, John C Klensin wrote:
> Unicode even though 3986 has a section of that title .

But we are supporting only the ASCII range of Unicode. We need to get 
our terminology right, but that does simplify matters significantly.

> It

That is my understanding as well.

> case-sensitive, or need to choose one of the three.

I lean toward removing it from the list, but I'd like to think about it 
more.

>  Note that,
> variations, etc., this is not a trivial decision.

ASCII only mitigates that concern. We are using the syntax from RFC 
3986, not RFC 3987.

> If we care

For p, q, and f components, I think that makes the most sense.

Peter

-- 
Peter Saint-Andre
https://andyet.com/