Ned, so I'm clear here: Are you supporting the Experimental protocol as specified? 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
