Clarify A-label vs U-label for public suffix / registrable domain

[annevk]

At the moment the Public Suffix List allows implementations to do either. The URL Standard clearly centers around A-label (ASCII) for everything normalized and expects the same from public suffix and registrable domain (due to the way it performs comparisons with them).

Filing this as a follow-up to #391 since we don't expose public suffix and registrable domain directly (yet).

I'd suggest we change

Return the public suffix obtained by executing the algorithm defined by the Public Suffix List on host.

to

Return the public suffix obtained by executing the algorithm defined by the Public Suffix List on host, using A-labels.

and do likewise for registrable domain.

Does that work @sleevi & @mikewest?

[sleevi]

@annevk I think it's in the right direction. The PSL doesn't make restrictions on its inputs, but implementations are presumed to enforce that their input aligns with their internal storage format (i.e. if you store as A-Label, you receive as input A-Labels, and you output A-Labels, ditto U-Labels). Some implementations I understand handle translation between A- and U- internally, and then align output to input format (so you can go A->A or U->U in the same implementation).

So this is good, and the only ambiguity is with the proposed wording, that is "using A-Labels" can be perceived as the transformation/assurance of the output, or the transformation/assurance of the input.

The overly verbose obnoxious way (i.e. @mikewest can word it better)

• Let x be the result of executing the algorithm defined by the Public Suffix List on Host
• Return x encoded using A-Labels

Just to avoid that ambiguity