[UA-discuss] Review of UASG018

[Marc Blanchet]

On 7 Jan 2019, at 11:19, Jim Hague wrote:

> On 05/01/2019 01:36, Jim DeLaHunt wrote:
>> /Page count/: was 24 pages in Version 0.96 (March 10th, 2017), the
>> previous copy I had locally. It is 17 pages in Version 1.1 (July 
>> 13th,
>> 2018). The list of changes don't explain to me how 17 pages was cut.
>> Some is editorial: a blank page 2 was dropped. But some must have 
>> been
>> substantive. The revision history should give a clue if scope was 
>> changed.
>
> As one of the authors of the initial version of UASG018, I was
> interested in what substantive changes had been made.

thanks for the review. A bit of rationale:
- we wanted to have a short, to-the-point, implementable, 
« scientific » list of test cases to be implemented in a test suite.

> On the basis of a
> brief review, I can summarise these as:
>
> 1. All non-technical library evaluation has been removed.

from rationale above, these were removed on purpose. Not that they 
don’t have any value, just we did not intend to fill those. Also, many 
of them are subjective and subject to interpretation.

> 2. Low-level tests removed:
> - L-R2A, IDNA2008, convert registration label to ASCII registry form.
> - L-DNC, IDNA2008, domain name equivalence comparison.
> - H-DND, Domain name, decompose into component labels.

Could not find many libraries (in those that we have tested) offering 
these operations/API.

> - H-ED, Email address, decompose into components (i.e. mailbox, 
> domain).
> - H-US, URL, syntactic check.
> - H-UD, URL, decompose into components (i.e. scheme, domain, user, 
> port,
> path, arguments)

IRI are in a bad shape currently in standards. There have been an IETF 
wg trying to fix the earlier RFC (which is essentially fairly incomplete 
and buggy) but the wg did not succeed and stopped. Moreover, there are 
browsers specs that differ from RFCs. So it is currently a difficult and 
non clear environment. Therefore, we decided to focus on domain name 
only of an URL/URI/IRI.


> 4. High-level test added:
> - H-ID, identifier lookup, compare identifier stored in the system
> against one used to authenticate user (whatever that means). Verify it
> follows RFC8264.

because email addresses are often used as identifiers in various 
systems, protocols, in authentication frameworks. (i.e. most web apps 
use your email address as username.) Therefore, its support is 
important, since if it does not correctly support your i18n email 
address as identifier, then you can not successfully login…: pretty 
big to me! And RFC8264 is the current standard for i18n identifiers.

>
> We would be intrigued to learn the rationale for these changes.

hope rationale and details above answers your questions.

Regards, Marc (on behalf of Viagenie team)

>
> The non-technical library evaluation is intended to summarise
> information developers need when deciding to incorporate a library 
> into
> a product. The aspects summarised are, in practice, at least as
> important as simple technical correctness.
>
> The removed tests all cover operations that application programmers 
> need
> to perform and, with the possible exception of L-R2A, need to perform
> frequently. These operations are complex to perform correctly within 
> an
> application, and so are very commonly not implemented correctly.
>
> Finally, we are puzzled as to the usefulness of H-ID in the context of
> UA. RFC5890 explicitly notes that it does not use Stringprep 
> (RFC3454).
> PRECIS(RFC8264), the successor to Stringprep, is therefore surely
> irrelevant to IDNA/UA?
> -- 
> Jim Hague - jim at sinodun.com          Never trust a computer you can't 
> lift.