Hi. Barry asked that I, as well as Patrik, expand a bit on what I said, off-list, to the IESG. First, let me stress that I think this is a worthwhile experiment and should go forward. I also believe it is entirely appropriate to include things about which we are uncertain in an Experimental spec. However, if we do, I think there is at least an ethical obligation for us to be clear about known areas of uncertainty and to consider them part of the experiment. The issues I see are with matters of definition and what the experiment is about. I see the document as fine on the definition of the MIME extension (plus or minus questions Ban Kaduk has raised in his IESG comments). Where I think there is a problem is that the message body content (<part-content> in the text) is a small subset of what we usually think of as plain text in UTF-8 but is not adequately defined (or the challenges with doing so identified). Patrik and I are focused on slightly different issues as most important but I should stress that we are, at least AFAICT, in complete agreement on what the issues are. I'm going to try to summarize the key ones for those who dislike long messages; I will follow up if needed with an inevitably-longer one with more details. The document's definition of the allowed characters incorporates Unicode UTS#51 (which the I-D references through [Emoji-Seq]) by reference. That is problematic in multiple ways that go beyond our criteria for normative references to documents produced by other bodies and how relaxed we should be about those criteria for Experimental specification. The I-D even indicates that the syntax for its key content syntax rule is inherited from UTS#51, but UTS#51 does not contain (or use) ABNF. The syntax definition language it uses is defined elsewhere in the family of Unicode specifications; someone trying to understand the syntax that the I-D supposed imports will need to understand much of Unicode. I think that is an unreasonable requirement but, if others disagree, the I-D should at least warn people about what they are getting into rather than saying "The ABNF rule Emoji-Seq is inherited from [Emoji-Seq]" and stopping. Another issue with UTS#51 is that the document, and the other documents and tables on which it depends, change with each version of Unicode to the extent that it is possible for a sequence to be invalid in one (annual or more frequent) version of Unicode and valid in another. That further complicates our long-standing problem (discussed in IDNA2008 and PRECIS) with how to handle unassigned code points. More on that, and especially about its rendering implications, if a longer note is needed. In general, while I believe it is reasonable to be more relaxed about definitions and other things because this is an Experimental spec [1], it seems to me that, if we do so and know those are problem areas, we are under some obligation to identify those areas and ask for feedback on whether they were problems in practice as part of the experiment. I see several possible ways forward but the most plausible one -- if we are to avoid going off in directions we have not explored before (and likely introducing significant delay) -- is, approximately: Leave the spec more or less as is but identify the issues with dependency on UTS#51 as an evolving document that is long (especially when the data files on which most of its definitions rest are included) and complex. Also identify the issues with alternate renderings and cultural interpretations that the new text in draft-crocker-inreply-react-09 makes a start on (but which I believe is too abstract to be useful without examples or more description). In addition, make it clear that part of the experiment is to gain some understanding of whether the use of emoji (or other types of reactions) cause cross-cultural problems (especially with multi-recipient messages with recipients in widely different locales), more complex features are used in practice, whether MUAs run into rendering problems, and whether the UTS#51 dependencies are problematic in practice. An alternative, the one I think Patrik is now suggesting after today's discussion, would be to limit the body content to a line consisting of one or more emoji drawn from an enumerated list of single-code-point emoji. That would considerably simplify the spec but might reduce the feedback we would get about interest and usability. Or, as I think Adam is suggesting, we could also allow symbol sequences, possibly drawn only from the ASCII symbol repertoire. If we were to do that, the question of whether emoji sequences and combinations were needed (i.e., whether there was significant user demand for them) should be explicitly part of the experiment. That approach would have the advantages of both eliminating the need for a reference to UTS#51 except for emoji definitions more specific than those in the I-D text and of expanding the possible range of "reactions". UTS#51 would become a relatively ordinary normative reference, one consistent with what it actually specifies. However, it would require us to agree on which code points are allowed and which are not and would not eliminate the need to discuss the cultural issues (particularly with regard to the hand gestures that are now included in the <base-emojis> set) and, if more than one code point is allowed on the line, raises possible sequencing, delimiter, and Bidi issues that we would need to at least consider and possibly sort out. And, before someone says "send text", I'm willing to do so but only when it is clear what the community consensus is terms of strategy. best, john [1] Thanks to Barry for a comment in an offlist note that helped me focus on this. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
