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@sinodun.com Never trust a computer you can't lift.