Dave, I think there is some misunderstanding about my concerns, so I'd like to back up a bit and review... To be clear upfront where I am going with this, I believe it would be acceptable (especially given that the issues did not arise during normal Last Call or earlier) for the document to be modified to indicate that concerns have been raised that the definition of emoji_sequence is problematic, with an example or two about why, and then to extend Section 7 to make clear that we are looking for input on the definition: whether it is comprehensible and allows too much or too little, and about any interoperability or inter-cultural problems it causes. I'd prefer to go a bit further (but only a bit); the background and reasons are discussed below. I believe that it has been generally understood since September or October that this draft is about expressing "reactions" (whatever that means) in emoji. I would have a good deal of sympathy if you took the position that the several suggestions to allow code points other than emoji and/or to allow verbal descriptions or keywords that could be turned into graphics by the receiving MUA are too late at this stage, but that is a topic that you might take up with the IESG either as a general issue or if a DISCUSS emerges asking that those proposals be considered. I think those late comments may be a sign that our Last Call process is failing for AD-sponsored documents and will probably take that up with the IESG or on the IETF List as soon as I figure out how to do better (and you or others should do so if you have good ideas first). But those issues are very different from my concern and Patrik's main ones: that <part-content> and <emoji_sequence> are not defined in a way that is likely to be helpful to the reader or implementer of the spec, that they will be interpreted differently (in part because UTS#51 is hard to understand and many implementers will guess rather than bothering), and that the current definition without some modification or qualification will weaken the experiment the I-D proposes. It is not really a separate matter because emoji and the definition leave everything entangled, but the possibility that the receiver may interpret emoji or strings of them very differently than the sender might intend, is at least a different part of the problem. I have tried to make clear in both my correspondence with the IESG and in my first note on this list in this thread that, while I would far prefer to get the definition nailed down to the extent that people know what to implement (including what should be sent and how strings that careful readings of UTS#51 would make clear are invalid are to be handled). A reasonable person could argue that even an IETF Experimental specification should not be adopted unless it is as clear as we know how to make it about what should be implemented and how odd cases should be handled but I have carefully avoided taking that sort of showstopper position. The difference between replacing the definition with a better one, one that would presumably depend on UTS#51 only for additional information, and handwaving our way around those issues by making them part of the experiment are great enough to motivate my resistance to writing text ... text that would almost certainly turn the discussion from that choice (even if non-emoji changes were excluded from the former option) into discussion of the text itself. Patrik and I have written a great deal more text in these messages but, at least for me, the motivation was to explain and document that the issues associated with the current definition are significant enough that it would be inappropriate to dismiss them as just not worth bothering with. Should the community decide that actually fixing the definition, or even supplying examples to explain open issues, is needed, much of the text can probably be taken from those notes, but, again, the motivation for them so far has been to demonstrate that the topic really is important. best, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
