Re: [I18ndir] I18ndir last call review of draft-ietf-regext-dnrd-objects-mapping-06

[John C Klensin <[e-mail]>]

Scott,

But that takes us full circle and into a set of problems that
are not I18N issues are all.

Given the number of times we have actually had:
 (1) A registry go out of business or been forced out by
	ICANN, and
 (2) The registry replaced by another one, and
 (3) These files used to populate the files for the new
	registry.

... It is hard to argue that there has been extensive
operational experience (and so I appreciate your use of
"supposedly".

And, while ICANN has run some tests to simulate such actions,
there have been, as you presumably, considerable suspicion that
there tests have been somewhat perfunctory.  Again, "supposedly".

In addition, if the only entities who care about this data
format and supporting protocols are ICANN, ICANN Contracted
Parties, and other ICANN-dependent entities, it takes us back to
my long-term concern about the REGEXT work and its boundaries:
if the real criteria for efforts like this document are that it
works for ICANN (however ICANN defines "works") then what is the
value of having the IETF involved?  Clearly, the work gets
better, and broader, review than ICANN could get without
spending money on expert reviewers and probably authors.  But,
despite occasional claims to the contrary, ICANN is not in a
state of poverty in which it could not afford those efforts if
they considered them important.   

>From an IETF standpoint, volunteer time that goes into this sort
of effort is time that is taken away from things that are
arguably more critical.  As a very specific pair of examples,
this directorate has a core IDNA document in AUTH48,
draft-klensin-idna-unicode-review, that I haven't been able to
spend time on in the last few days because Marc's review had to
be prioritized so that any necessary revisions could get into
the LC process before the, IIR, 9 March cutoff.  not clear to me
that is the right optimization for IETF or the Internet.

best,
   john


--On Friday, March 6, 2020 17:05 +0000 "Hollenbeck, Scott"
<shollenbeck=[e-mail]> wrote:

> It is what it is, Asmus. I'm not so sure that it is, in
> fact, critical. ICANN has supposedly been using this archive
> format for years with no interoperational issues.
> 
> 
> 
> Scott
> 
> 
> 
> From: I18ndir <[e-mail]> On Behalf Of Asmus
> Freytag Sent: Friday, March 6, 2020 11:52 AM
> To: [e-mail]
> Subject: [EXTERNAL] Re: [I18ndir] I18ndir last call review of
> draft-ietf-regext-dnrd-objects-mapping-06
> 
> 
> 
> As I read the W#C document, "NormalizedString" is not an
> actual format, other than that it disallows all line endings
> and tab.
> 
> 
> 
> There are parameters for how to normalize remaining
> whitespace, but without specifying which parameters are set.
> It's like calling a string "Unicode normalized" and not
> knowing from that term whether it's in NFC, NFD, NFKC or NFKD.
> 
> 
> 
> In the W3C these are enumerated as part of the "constraining
> facets" listed in 3.3.1.1
> 
> 
> 
> For an archival format, then, either each field has attributes
> that give these facets, as applicable, or the format itself
> needs to require particular settings.
> 
> 
> 
> None of that, by the way, speaks in any way about casefolding
> or Unicode normalization, the kinds of operations that are
> critical in identifier contexts.
> 
> 
> 
> A./
> 
> 
> 
> 
> 
> On 3/6/2020 7:55 AM, Hollenbeck, Scott wrote:
> 
>    Note below on the draft's reference to the XML Schema
> normalizedString data type:
> 
> 
>       -----Original Message-----
>       From: I18ndir
> <[e-mail]><mailto:[e-mail]> On
> Behalf Of John C Klensin       Sent: Friday, March 6, 2020
> 10:46 AM
>       To: Asmus Freytag (c)
> <[e-mail]><mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>       Subject:
> [EXTERNAL] Re: [I18ndir] I18ndir last call review of
> draft-ietf-regext-       dnrd-objects-mapping-06
> 
> 
> 
>    [snip]
> 
> 
>       [1]  I am not familiar enough with the Regext set of
> documents to know if       "normalizedString" is defined
> somewhere.  Certainly,
> draft-ietf-regext-dnrd-objects-mapping-06 uses it without
> defining it locally       or providing a specific normative
> reference to such definitions.  At minimum,       this
> suggests another problem with the I-D that may need fixing.
> But, if       there is not a clear definition -- if the
> instruction for what should go into       those fields is
> essentially "just normalize", than that is obviously bad news.
> It       is bad news even for IDN U-labels because a string
> in, e.g., NFC would not       conform to the requirements for
> U-labels.  Normal IETF and RFC practice       requires a
> statement, probably in the Terminology section and probably
> with       a normative reference, to where definitions of that
> and other attributes can       be found.
> 
> 
>    Reference here:
> 
>    https://www.w3.org/TR/xmlschema-2/#normalizedString
> 
>    The draft should include a normative reference to the W3C
> XML Schema specification:
> 
>    http://www.w3.org/TR/2004/REC-xmlschema-2-20041028
> 
>    Scott
> 
> 
> 
>