Re: [Last-Call] New Version Notification for draft-crocker-inreply-react-07.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Sunday, 28 February, 2021 11:59 -0500 Ricardo Signes
<rjbs@semiotic.systems> wrote:

> On Sat, Feb 27, 2021, at 4:50 PM, John C Klensin wrote:
>> Take "should free Unicode text be allowed in reactions?" as an
>> example and put aside the issue that "text" does not have a
>> uniform meaning in Unicode discussions.  The I-D now says "no"
>> even though it may not be easy to figure that out.  If the
>> spec is followed strictly, then I think John (and some others,
>> including me on odd-numbered days) are not only predicting it
>> will fail, but that it will probably fail badly enough that
>> the IETF would be wasting the community's time by publishing
>> it. However, put a sentence in somewhere indicating that the
>> choice or all of what UTS#51 allows and only what it allows
>> as an Emoji Sequence (UTS#51, version 13.1, ED-17) is known
>> to be controversial and one in Section 7 asking for feedback
>> on whether users insisted that implementations be more or less
>> restrictive (and whether more or less) would, I think, both
>> solve the problem, considerably improve the experiment, and
>> let us move forward.
> 
> I am sincerely unsure what this paragraph means.
> 
> Do you mean that you (sometimes) feel that disallowing (for
> example) the reaction "Nice!" (that sequence of five
> characters) is likely to doom the proposal?  Or are you saying
> that the complexity of validation of the part-content is too
> high, and that it will too often be done wrong?
>...

Sorry to not have been more clear.

There are a few separate issues getting tangled up here and, if
my paragraph above makes sense at all, it may do so only in the
context of the rest of the note.  To avoid a long message, let
me identify only two of the issues.

(i) Paraphrasing what Dave has said several times (and hoping he
will agree with this characterization), it is unfortunate that
the issues of the definition of what can appear in the body part
were not raised much earlier.  I don't think a debate about why
that didn't occur is helpful: as far as I know, IETF procedures
and precedents have never allowed dismissing substantive
technical objections on the grounds that they were made at an
inconvenient time.  However, AFAIK, all of the discussions of
this draft prior to the last week or so have focused on emoji
and at most one line of emoji.  If free text is going to be
permitted in addition, and multiple lines of free text at that,
it becomes, IMO, a rather different proposal with far less
justification for treating a "reaction" as different from a
text/plain body part with a UTF-8 charset, perhaps with some
sort of priority indication.   I'm not sure Content-Disposition
would not still be the right way to deal with that, but it would
almost certainly a big enough conceptual change to justify
ending the Last Call and going back to discussion on an ordinary
mailing list.

(ii) Free text opens up another issue that we have not discussed
in this context.  I don't see an issue with "Nice!" or even with
"Can of worms".  However, given what the rest of the document
says and the focus on emoji, it seems to me that it would be
important to clarify whether, e.g., 
     Nice! grinning-face
was expected to be interpreted using the relevant graphic, i.e.,
whether parts of the string should be treated as emoji
indicators (or, as UTS#51 would have it, annotations).  If the
answer to the above is "it is all just text" (without thinking
about this much, I think any other conclusion would lead to
madness, especially as emoji are added to Unicode), how about 
    Nice! :grinning-face:
    Nice! \N(grinning-face)     or
    Nice! \u(1F600)
and, if so, which one(s)?

If the answer is that what follows "Nice!" in any of those forms
is that we expect the emoji symbol to be produced, then is
text/plain still appropriate or should we be talking about,
e.g., text/emoji content?

I haven't formed opinions about any of those questions or
options but, because the answers don't seem obvious, if we need
to address them, it would seem obvious we would then have a
somewhat different (and, incidentally, more complex) proposal
that should go back to the ietf-822 list for discussion and
refinement rather than continuing on the Last Call list.

Those questions are, of course, independent of my concerns about
the implications of expecting or wanting to enable tabulation.

It seems to me (YMMD and, to a certain extent, only Barry's
opinion and then that of the IESG count) there are three options
here:

(1) Conclude that my concerns and/or Patrik's about how
<part-content> and <emoji_sequence> are defined in the document
are not significant and just move forward with the document as
is.

(2) Conclude that those concerns are significant but that they
can be dealt with by adding the kind of "health warning" and
"part of the experiment" text I/we have suggested, get that text
added, and move forward with the document.

(3) Conclude, presumably based on the discussion and other
suggestions made in the last week, that the Last Call was, as
John Levine put it, premature and that it should be withdrawn so
that more discussion about what was actually intended can occur,
presumably on the ietf-822 list.

Personally, I am still pushing for (2).  However, I think every
time someone says something like "the part-content should be
allowed to have free text", "multiple lines should be allowed",
"require white space between emoji graphemes", or "we should
restrict (or expand) the <base-emojis> list or restrict <emoji>
to an enumerated list rather than <emoji_sequence> and a broad
reference to UTS#51", and gets any traction, I think it takes us
closer to concluding the document was not carefully enough
developed and discussed and that we should go back to (3).

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux