No, This is really a partner-negotiation when LTI is to be used. In other specifications we do mention that it advisable to use Unicode/UTF-8. In LTI, though, the specification does not say how or with which Unicode subsets the transfer of messages should be done. This is what is called an implementation detail, and it is very much a negotiation between the partners trading LTI messages. As adoption of LTI specs have grown in number, though, these problems do appear more and more often. You and your partners must agree on the message formats to use so that the messages are readable. The use of this type of unhelpful or formal language for implementation details is simply to prevent the automatic expansion or narrowing of programming language choices. Some programming languages deal with Unicode differently or not at all (or are just beginning to do it right). Required implementation details such as Unicode support are the kind of things that potentially could prevent unnecessarily wide adoption of the standard. In fact there are many (albeit older) implementations of LTI using older versions of programming languages like PHP where there were _no_ Unicode supports at all (as an example) and all messages would just be assumed to be ASCII. That is of course not the world we live in, but those implementations are valid and work well in specific markets and with the partners involved.  By using UTF-8 you will be casting the widest net practical for most applications, but it is really up to your organization to make the decision.