You can already send arbitrary bytes over the wire, and nothing in this document changes that.
Indeed, you can already send an email with these exact sequence that Barry is mentioning here, and have it rendered "correctly" in the body of an email.
Recipients already need to sanity check anything coming in, and could block any sequence they don't like.
Literally the only point of a standards document referencing something like UTS#51 (apart from the initial guidance to allow people to create something compatible) is so that if something doesn't work, then in a discussion between the sender and the receiver there's a documented version of who is more correct.
I'm with Dave on this still - this whole discussion seems like some baulking at shadows which aren't there.
Bron.
On Tue, Mar 2, 2021, at 06:22, John C Klensin wrote:
Barry,Thanks... and yes. I want to again stress that I have notproposed changing basic assumptions about the protocol, only toclarify the range of the experiment and warn about a fewpossible issues. I've also realized, after reading Ned's note,that I (and maybe Patrik) should perhaps have explained ourconcerns a little bit differently. I want to think about that abit more lest I post a quick response that confuses thingsfurther but will try to explain later today.john--On Monday, 01 March, 2021 12:20 -0500 Barry Leiba<barryleiba@xxxxxxxxxxxx> wrote:> 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 mailing list
--
Bron Gondwana, CEO, Fastmail Pty Ltd
brong@xxxxxxxxxxxxxxxx
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
