Barry,
Thanks... and yes. I want to again stress that I have not
proposed changing basic assumptions about the protocol, only to
clarify the range of the experiment and warn about a few
possible issues. I've also realized, after reading Ned's note,
that I (and maybe Patrik) should perhaps have explained our
concerns a little bit differently. I want to think about that a
bit more lest I post a quick response that confuses things
further 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@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/last-call
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
