Re: [Gen-art] Genart last call review of draft-crocker-inreply-react-07

[Dave Crocker <[e-mail]>]

On 1/31/2021 2:16 PM, Dale R. Worley wrote:
> Dave Crocker <[e-mail]> writes:
>> On 1/27/2021 6:32 PM, Dale Worley via Datatracker wrote:
>>>      The emoji(s) express a recipient's summary reaction to the specific
>>>      message referenced by the accompanying In-Reply-To header field.
>>>      [Mail-Fmt].
>>>
>>> This is not specific as to where the In-Reply-To header is.  I assume
>>> you want to say that it is a header of the parent multipart component
>>> of "Reaction" part.  Or perhaps this should be forward-referenced to
>>> the discussion in section 3.
>>
>> I don't understand the concern.  An In-Reply-To header field is part of
>> the message header.  That is, it will be in the header of the response
>> message.
> 
> Given that we're deailing with multipart messages, an In-Reply-To header
> could be stuck in the message header but it could also be stuck in the
> headers of any part.  I don't know if it's ever done, but certainly,
> it's plausible that if I include a reply which I had received as an
> attachment to another email I send, the In-Reply-To header in the
> received e-mail would show up as a header to the attachment part, not
> my message as a whole.
> 
> In general, the situation is one of unlimited complexity.

RFC 5322's definition of the In-Reply-To field has it being optionally 
present in the message header:

       message     =  fields *( CRLF *text )       ; Everything after
                                                  ;  first null line
                                                  ;  is message body

      fields      =    dates                      ; Creation time,
                       source                     ;  author id & one
                     1*destination                ;  address required
                      *optional-field             ;  others optional


      optional-field =
                  /  "In-Reply-To"       ":"  *(phrase / msg-id)


As such, it's location is not as random or varied as you seem to think. 
  Also note that the In-Reply-To field has long history and is already 
well-integrated into MUAs.

So, the complexity is quite limited.

My guess is that you are confusing the variable venues possible for the 
emoji-sequence with the far less variable venue of In-Reply-To.

I suppose a clarification could be added along the lines of:

OLD:
    The emoji(s) express a recipient's summary reaction to the specific
    message referenced by the accompanying In-Reply-To header field.
    [Mail-Fmt].

NEW:
    The emoji(s) express a recipient's summary reaction to the specific
    message referenced by the accompanying In-Reply-To header field, for
    the message in which they both are present. [Mail-Fmt].

If a message is nested within a message, that defines a hard reference 
boundary.  Something inside the nested message does not refer to the 
containing message, for example.


> I'm not particular what rules you want to specify, just that when I'm
> looking at a part with this Content-Disposition that is somewhere in a
> multipart structure (possibly without parts), that it's clear which sets
> of headers I need to examine to find the In-Reply-Header.

Perhaps you could offer an example or two of messages that you see as 
creating ambiguity or other confusion?


> Now I think in reality, it either has to be in the headers of the part
> with disposition "reaction", or in the multipart containing that part.
> But whatever the rule is, it should be stated.

see above?


>>>      Reference to unallocated code points SHOULD NOT be treated as an
>>>      error; associated bytes SHOULD be processed using the system default
>>>      method for denoting an unallocated or undisplayable code point.
>>>
>>> Code points that do not have the requisite attributes to qualify as
>>> part of an emoji_sequence should also not be treated as an error,
>>> although you probably want to allow the system to alternatively
>>> display them normally (rather than as an unallocated or undisplayable
>>> code point).
>>
>> I think your comment addresses a different issue than the cited text is
>> meant for, but I also might be misunderstanding.
>>
>> For whatever reasons, including not having been allocated by the Unicode
>> folks, or possibly by running an older system that thinks a code point
>> is not allocated, there is an issue of how the system should deal with
>> encountering such a code point.  The text here is merely trying to say
>> "do whatever you do".
> 
> The text is a constraint, though.  It *requires* (sort of) that if the
> bytes in the part form a character which the receiver considers
> unallocated, it *should not* reject the whole message as being
> ill-formed.  The implementation has great freedom in how to display the
> caracter, but the message as a whole "SHOULD NOT be treated as an
> error".

Since this specification pertains to processing of some octets, rather 
than having anything to do with overall processing of the message, I am 
not understanding your concern.

A system that might reject an entire message because the system is 
unhappy with one or another of the octets in the message is playing its 
own game, which has little or nothing to do with Internet standards, I 
believe.


>> A different issue is encountering a code-point, here, that is outside of
>> the emoji-sequence set. The text doesn't try to tell the receiver how to
>> process bytes that are illegal here.
> 
> Perhaps that is what you intend, and if so, the text is correct.  But it
> seems to me that if the bytes form a code point that the receiver
> considers to be allocated but not an emoji, it should be under the same
> constraint that it should not reject the message as a whole as erroneous.

I think you are describing a system that is not implementing the 
specification carefully.  Or, perhaps, is going beyond the scope of the 
specification.


> Now for the messy part:
...
> 
> When I wrote my review, I was aware only of the first composition layer.
> But now, it's not clear to me what the sentence "It permits one or more
> bytes to form a single presentation image." is intended to say.  The
> combining of bytes to form an image may happen at any of the three
> layers, and it seems to me that the entire process would be better
> described as "It permits one or more bytes to form one or more
> presentation images."  But maybe you're trying to say something more
> specific.

(Note that we've settled on 'octet' rather than 'byte' or 'character'.)

The text using that word is correct, because it is referring to -- for 
this context -- the lowest-level of data object.

Some things that get displayed do in fact take a single octet. Others 
take more.

That there might be an interesting internal sub-structure to the 
interpretation of a string of octets is highly relevant to the display 
or semantic processing of that string, but I believe it's not relevant 
to the point covered by the text in question.



d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net