Ale,
Thanks for the careful reading. Inline below...
--On Sunday, August 4, 2019 12:04 +0200 Alessandro Vesely
<vesely@xxxxxxx> wrote:
> On Fri 02/Aug/2019 22:30:42 +0200 The IESG wrote:
>
>> Please send substantive comments to the ietf@xxxxxxxx mailing
>> lists by 2019-08-30.
>
> None of the following comments is substantive, but the wording
> above doesn't seem to prevent to send them anyway...
>
>
> Introduction:
>
> Instead, the algorithm and rules of RFC 5981 and 5982
> eliminate many
>
> s/598/589/
Sorry. Careless idiot at keyboard. Fixed this and other
instances. And thanks for spotting it.
> BTW, writing RFC NNNN and RFC NNNM instead of RFC NNNN and
> NNNM would improve the htmlized version of the paper.
And degrade the quality of the English, at least IMO. It
should, however, have been "RFCs NNNN and NNNM" and I've fixed
that. I hope the change doesn't make the HTMLized version worse
-- for the final version, this is really up to the RFC Editor.
> Registry Restrictions in IDNA2008:
>
> somewhat longish:
> The most obvious
> of those restrictions include provisions for restricting
> suggested new registrations based on conflicts with labels
> already registered in the zone and specifications of what
> constitutes such conflicts based on the properties of the
> labels in question. The definition of "conflict" is
> outside the scope of this document.
>
> possibly clearer(?):
> The most obvious
> of those restrictions include provisions for restricting
> suggested new registrations based on conflicts with labels
> already registered in the zone, so as to avoid homograph
> attacks and other nuisances. The specifications of what
> constitutes such conflicts, as well as the definition of
> "conflict" based on the properties of the labels in
> question, is the responsibility of each registry.
Much better although I've changed "nuisances" to "issues" to
avoid needing to have an argument about how important those
conflicts are.
> Progressive Subsets of Allowed Characters
>
>
> They also interact with recommendations about how labels
> that appear to the the same or apparently the same should
> be handled.
>
> "Apparently appear"? Why not use proper terms (homoglyphs,
> homophones, homographs, transliterations)?
<rant, with apologies>
Because those terms, especially the first three, have been used
in sufficiently sloppy ways that using them without definitions
might add more confusion than it eliminates. I note that the
first three do not even appear in RFC 6365 and that, if 6365
were being revised [1], I'd want to revise the definition of the
last one. More important, your list doesn't cover all of the
cases: we should arguably be paying more attention to whether
synonyms, near-synonyms, orthographic variations, or actual
translations are "confusing" or "the same" [2]. </rant>
> s/the the/be the/
I am clearly in need of a copy editor. Thanks.
thanks again,
john
[1] If you, or anyone else, believes that RFC 6365 is in need of
revision and who is willing to put time in on the effort, you
should discuss the issues, including the issue of whether there
is enough energy in the IETF to process such a revision, with
the ART ADs. I haven't discussed it with Paul, but I'd be
willing to plunge back in if there were real energy in the
community, but not to start and then sit around for as many
years as this 5891, etc., clarification has while the IETF
decides whether it is in the i18n business.
[2] We (going back to the active IDNABIS WG participants or
earlier) have tried to keep IDNA from being bogged down in those
issues. Some of us have also recognized (in analyses that go
back to 2005 and earlier) that the typical user of the Internet
doesn't know, and doesn't want to know, the difference between a
domain name and a search term, and that contemporary search
engines blurs those distinctions even further, for example,
treating clearly incorrect spellings as matching or confusing if
the errors follow specific patterns or are made often enough.
To some extent, those behavior patterns make the whole
discussion of "matching" or "confusing" names either irrelevant
or far harder than our usual discussions would imply.
Personally, I'm happy to discuss those issues and how they might
be mitigated at any time (ideally in the presence of strong
drink), but, for this document, I think the IETF and the
community are better served by straying as little as possible
away from the scope of the base IDNA documents.
