[UA-discuss] Review of UASG018

[Jim Hague]

On 07/01/2019 17:31, Marc Blanchet wrote:
> On 7 Jan 2019, at 11:19, Jim Hague wrote:
>> 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.

OK, thanks. I think this is a bit of a change of emphasis, then; we were
aiming at producing a document that would guide developers in their
choice of a library and inform them of how much of the functionality
they might require is present.

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

There is, indeed, some subjectivity, which is why those items are not
scored. We did feel they were items developers would need to make an
decision about a library. Put it another way, it's certainly information
that would heavily influence any decision I might make about the worth
and usability of any library I'm evaluating for use in my applications.

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

That's true. Again, we were starting from the point of view of functions
that developers might need from a library, and rating libraries against
those potential needs, with a view to informing library authors/vendors
about items that would be required to improve UA takeup.

We feel that the current state of library availability and range of
functions inhibits correct implementation of UA. However, if the goal of
this document is moved to just document current provision, removing the
tests is consistent (though in the case of L-DNC, I note that at least
one major library does implement that function).

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

I understand that IRIs are a minefield; our intention was that
developers might have access at least to current best practice functions
and have a clear understanding of their limitations rather than carry on
rolling their own.

Does the same apply to email address decomposition?

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

Our version of the document pre-dates RFC8264, so adding a test for
PRECIS identifier comparison is a good thing and (if I read the RFC
correctly) forms a superset of L-DNC, where L-DNC is H-ID with the
IDNA2008 profile.

However, looking at the case of a email address as identifier, is it
your intention that two email addresses with different domains that
compare equal under IDNA2008 should compare equal when passed to H-ID?
In other words, that H-ID will spot they are email addresses, decompose
to mailbox and domain, and perform type-specific comparison on each? I'm
wondering why this function is classified high-level, rather than being
presented as a simple low-level comparison or transformation function?
-- 
Jim Hague - jim at sinodun.com          Never trust a computer you can't lift.