I think it's best for us to back this up to John's note suggesting that we: (1) Add a paragraph about emoji sequences (specifically, things that might combine emoji characters in possibly problematic ways, such as applying skin-tones, grouping several person symbols into one "family" symbol, and the like), which would briefly explain why they can be problematic and give an example or two. (2) Add something to the experiment description (Section 7) that talks about getting feedback about any understandability issues and culture clashes. I would see (1) as also leading us to eliminating emoji-sequence as a normative construct (so, just leaving things as a string of emoji characters, some of which could form an emoji sequence) and moving TS51 to informative. Are there real objections to that? I'm sure we can quickly come up with some brief text that accomplishes this and then move forward. Barry On Mon, Mar 1, 2021 at 9:07 AM Dave Crocker <dcrocker@xxxxxxxx> wrote: > > On 3/1/2021 12:03 AM, John C Klensin wrote: > > However, the specification as now written incorporates all or > > UTS#51, a long (very long if the required supporting tables are > > considered( specification of what several people outside the > > IETF have described as a Unicode-based picture language of very > > high complexity that is necessary to understand. > > > > Discussion of this draft was conducted on the ietf-822 mailing list for > two months, last September and October. Early in October, the spec > added the UTS#51 reference. > > You participated in the ietf-822 discussion but did not raise any of the > concerns you are now offering as being critical. Nor did anyone else. > > What has changed? > > > > Above you make a claim to controversy about this specification. I've > looked and am not finding it. Please provide a reference the rest of us > can use to review it. > > > > For all of the concerns you insist are fatal to the current > specification, you have yet to offer an alternative that can be compared > against it. > > Suggestions for modifying the specification, to add various constraints > or commentary surrounding the use of UTS#51 pertain to that external > specification and not to its use here. > > That is, you are pressing for having an IETF specification contain > tutorial material about another standard body's work or to declare some > constraint on the use of that work -- though we can't yet tell what > constraint you would find satisfactory, in spite of your multiple, > extended postings here. > > > > There is a simple reality that that external work has been around for > awhile and has field experience. To the extent that there are nuances, > complexities, or the like, that area of work has been developing it. > The IETF hasn't and should not pretend to exercise expertise about it. > > > > Then there is the small matter that this specification is intended as > Experimental. That's supposed to allow room for gaining experience. > > If the horrors you fear do appear, we'll find out, won't we? > > > > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
