> Ned, so I'm clear here: > Are you supporting the Experimental protocol as specified? ??? Of course I support it. My comments below were focused entirely on the proposal to expand the scope of the project to include some kind of mapping in an attempt to solve the "different pictographs mean different things to different people" problem. Which is the kind of problem I enjoy discussing, but actually trying to solve, not so much. Ned > Barry > On Wed, Feb 24, 2021 at 2:34 PM Ned Freed <ned.freed@xxxxxxxxxxx> wrote: > > > > > On 2/24/2021 9:20 AM, Barry Leiba wrote: > > > > I wonder, then, if it doesn't make more sense to send reactions as > > > > defined protocol elements that can be localized, and a "Yes!" reaction > > > > could show as a thumb-up emoji in locales where that's appropriate, > > > > and as something else elsewhere. > > > > > > > Barry, > > > > > Thanks for the clarification. And, in fact, I now recall seeing this > > > concern, but not by whom or where. > > > > > In any case, it's certainly an interesting conceptual issue. > > > > > It is also a completely different task than the current one has undertaken. > > > > It's also a draft of a prospectus for a potential series of research projects, > > some of which nobody would dare undertake in the present political climate. It > > isn't close to a research project, let alone an experiment. And it's light > > years away from a possible standard. > > > > Let's think about this for a moment. There are basically two ways to do this > > with any sort of generality, one using existing emoji and the other not: > > > > (1) Define a set of meta-emoji that map to specific emoji in a > > culture-specific way, and > > > > (2) Develop a more abstract way of defining a set of semantic units > > repesentable in pictoral form and then develping culture-specific > > pictograms that actually experss them. > > > > I'll first note that both of these approaches depend on there being some sort > > of culture registry. Given that what one some people think defines a culture is > > taken by the practitioners of that culture as a highly offensive > > characterization, lots of luck doing that. (On a personal note, this Okie > > doesn't much care for the term or the grouping it defines, its legitimacy as a > > shared culture notwithstanding. A Boont may well feel differently about it, but > > I'm not a Boont.) > > > > But let's ignore the registry issue for a moment. (1) is principle doable, > > although I'd implement it by documenting the reverse mapping and then inverting > > it. But now you have something that has a lot in common with Han unification. > > And we all know how that went, as well as how futile our attempts were to help > > out with tagging so different pictograms could be used. > > > > As for (2)... you would first have to define an appropriate universal semantic > > space, in the process deciding whether or not to include pictographs like, say, > > "I Can't Breathe Barney". Once this space is defined you would think have to > > parameterize and discretize it in some way. I can already hear the linguist's > > laughter. > > > > Looks to me like a general approach is not in the offing. How about a more > > constrained approach, like the limited set of indicators provided by some > > interfaces? > > > > First of all, I don't think you're going to get much past a dozen or so > > indicators before you run into trouble. And there are countless use-cases for > > reactions where a limited set of indicators isn't going to cut it. And given > > that very limited set is almost certainly representable in a fashion acceptable > > to most cultures using existing emoji - why not only allow that limited set in > > your application if that's a requirement? (And if some of those emoji are > > actually missing, well, that's what codepoint additions are for.) > > > > > A notation for shared affect semantics could be a fun effort. Not for > > > the IETF, but for some group. And 'fun' doesn't mean 'productive'. > > > It's the sort of effort that is appealing but extremely difficult, for > > > standardization. > > > > Dave, ever the optimist. > > > > > Rather, the current effort seeks only to document and, eventually, > > > standardize, *existing practice*, albeit from a different service > > > environment. This is always easier and more pragmatic. > > > > > That's not to deny that appeal of what you describe, merely that what > > > you have described is a very different -- and far more difficult -- task. > > > > > There are a number of times, over the years, where similar choice has > > > been made. DNS country codes come to mind. The thinking then proved > > > quite useful and is, I think, the same here: Some other group has a > > > serious effort to standardize a difficult construct. So let's just use > > > their work. > > > > Language codes are probably a better example - the fights over some of those > > were epic. (And for all I know are still happening - I dropped out of that > > discussion many years ago.) And even once we had them, getting people to use > > them for pictogram selection just didn't happen. > > > > > That's what the current specification does. > > > > And IMO all it should do. > > > > Ned -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
