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

[Marc Blanchet <[e-mail]>]

On 6 Mar 2020, at 12:45, John C Klensin wrote:

> 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".

I think this discussion is out of scope of this document and its review. 
This document describes an archival format of data. It does not 
describes what the custodian should do with it in case of its need. In 
that situation of doing something with the data, this is not a protocol 
but a best-practice-document-to-read-archival-files, which is to me not 
in the IETF realm. That best-practice-document-to-read-archival-files 
could include information about normalization, case folding, and other 
nice stuff we could think about. But again that 
best-practice-document-to-read-archival-files is in fact in ICANN realm 
not IETF’s. This archival format document do not necessarily need to 
talk about those subjects.

>
> 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,

well, ccTLDs are often following what ICANN is doing (they are not 
obliged to, but often have many advantages to reuse).
So overall, that is pretty much a big set of Internet infrastructure 
components that cares about this stuff.

And we have seen other protocols that you could claim to be ICANN’s 
such as RDAP that included the RIR needs since the beginning. Nowadays, 
there are other organizations and protocols considering RDAP for other 
uses. So it seems to me that this « this-work-is-only-for-ICANN » a 
bit reductive to its value.  I could think of many IETF protocols that 
have a much more narrow scope than protocols/documents related to ICANN.

So I agree with you that, taking my example above, the 
best-practice-document-to-read-archival-files-to-be should be written by 
ICANN community, not here.

Regards, Marc.

> 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
>>
>>
>>
>>
>
>
> -- 
> I18ndir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i18ndir