SQRL character set?


MacNala

Member
May 20, 2018
7
0
UK
I am finally getting back to my long term goal of developing SQRL using PHP for servers.
I want opinions on the character set that should be used for details in the internal database/s.
I am planning (or hoping to ) to make the server code useful for a global audience.
Initially I will be using UTF8 for the development stage but being a future planning sort of chap I
want to make the changes that would be needed to implement the code in a foreign language
as easy to make as possible.
Since I shelved this project some two or more years ago I have found that the goalposts have been moved
and UTF8 is not sufficient any more. MySQL version 8 is upon us and a possible change to PHP version 8 is
also on the horizon.
What are your opinions and reasons for suggesting alternatives.
utf8mb4 or what?
The database for internal working will also have to be chosen, suggestions?
 

Jaap

Member
May 20, 2018
17
2
Yes pick the least broken of MySQL's utf8 encodings.
And about normalization, Steve said:
Our goal would be to improve compatibility among clients, rather
than to attempt to preserve non-significant differences between
equivalent characters. And we don't want to break our existing
implementations as we rigorously define this character
transformation. So I think that argues for the compatibility
choice over the canonical choice, and for forming composed
characters rather than decomposed characters, thus the
transformation known as "NFKC"
 

PHolder

Well-known member
May 19, 2018
250
54
Does the server even care about character set choices? The spec defines the correct outputs, and those have to be what they are. In the database, the only necessary to store is binary, and there is no character set for that.
 

MacNala

Member
May 20, 2018
7
0
UK
Does the server even care about character set choices? The spec defines the correct outputs, and those have to be what they are. In the database, the only necessary to store is binary, and there is no character set for that.
Well I was, in my uneducated way, trying to think of the possible characters that a client might use if they were in Japan or China. You may not consider that important but I want to have thought of all the possibilities before hand.
 

Jaap

Member
May 20, 2018
17
2
Hmm no @PHolder has a point.
In the communication between SQRL client and SQRL server there is almost no textual data.
Perhaps with the exception of the "ask" parameter (i forgot).
 

MacNala

Member
May 20, 2018
7
0
UK
Hmm no @PHolder has a point.
In the communication between SQRL client and SQRL server there is almost no textual data.
Perhaps with the exception of the "ask" parameter (i forgot).
I agree but I am considering other interactions between client and server, such as registering after establishing valid connection.
 

PHolder

Well-known member
May 19, 2018
250
54
other interactions between client and server
All well and good, but not part of the SQRL protocol, so up to the server implementation to decide. Internationalization (I18N) is a significant topic for developers to plan and implement.
 

MacNala

Member
May 20, 2018
7
0
UK
I expect to be able to read posts in this sort of forum without having to resort to Google (*&*^ bad taste in mouth just typing that word).
Thanks, however for the explanation.