--On Thursday, February 25, 2021 17:55 -0800 Dave Crocker
<dcrocker@xxxxxxxxx> wrote:
> On 2/25/2021 4:03 PM, John C Klensin wrote:
>> the I-D
>> should at least warn people about what they are getting into
>> rather than saying "The ABNF rule Emoji-Seq is inherited from
>> [Emoji-Seq]" and stopping.
>
> At Barry's suggestion earlier today the next version of the
> draft already contains:
>
> <t>The ABNF rule emoji_sequence is
> inherited from <xref target="Emoji-Seq"/>. It defines a set of
> octet
> sequences, each of which forms
> a single pictograph. The BNF syntax used in [Emoji-Seq] differs
> from <xref target="ABNF"/>,
> and MUST be interpreted as used in Unicode documentation.</t>
An improvement, but does not quite work. First of all, IIR, the
only Unicode materials that talk about octet sequences are those
that deal specifically with Encoding Forms. UTS#51 is not one
of them. It mentions only "code points" and "characters" in the
context of what you/Barry are getting out. The I-D can talk
about octets if it very careful to confine itself to characters
on the wire, where a Content-type of text/plain; charset=utf8 is
specified, but the string might not be in UTF-8 by the time the
MUA gets it. Even then, it seems to me the above is really
talking about code points. Second, my biggest concern about the
original language about inheriting ABNF isnt the difference
between the two syntax notations themselves. It is that the
notation used in UTR#51 involves operators that are vital to
understanding what is going on but than are not defined (or the
definition referenced) from within it. "interpreted as used in
Unicode documentation" is true, but is handwaving that will be
of no help to someone trying to use UTR#51 to figure out what is
being specified.
That gets back to emoji_sequence and the incorporation of
[Emoji-Seq]/UTS#51 by reference. If our intent is to say
"you'd better understand Unicode and its documentation
conventions and then study UTS#51 in particular", I'm probably
ok with that but my experience suggests that very few
implementers or designers --at least those similar to the subset
who participate in IETF -- will bother they will just guess what
UTS#51 say and move on (some may look quickly at UTS#51 first;
others won't bother even trying. Otherwise, we should be, IMO,
providing pointers or hints. I won't feel that way if it were
straightforward, but UTS#51 uses \p() and \P() notation. Do you
know what they mean? Are they case-sensitive (i.e., the two are
different) or not? And do you know where to find the
definitions (hint: the index to TUS 13.0 does not contain any of
the terms "syntax", "metalanguage", "operator", or "expression")?
>> it seems to me that, if we do so and
>> know those are problem areas, we are under some obligation to
>> identify those areas and ask for feedback on whether they were
>> problems in practice as part of the experiment.
>
> Send text.
As I indicated in my note, I believe this is a case in which we
need to reach some sort of consensus about what we want to do
first. Text that is linked to specific suggestions or issues is
likely to be an invitation for tours of assorted bikesheds (and
discussions of the kind of details of terminology that appears
above) if it is supplied before there is agreement about what
problems are worth solving.
john
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
