Re: [Last-Call] Benjamin Kaduk's Discuss on draft-crocker-inreply-react-08: (with DISCUSS and COMMENT)

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

 



On 2/25/2021 11:11 AM, Benjamin Kaduk wrote:
Could you please confirm whether the lack of response to the COMMENT
section was intentional and no further comments are forthcoming?

The drats just keep on coming.  Sorry.  It was completely NOT intentional.  I stopped at the Discuss and forgot that there might be Comments.

So...

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

    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].  For
    processing details, see Section 3.

I don't think I understand what "for the message in which they both are
present" is intended to mean (specifically "for the message").  My best guess
is that "when both 'Content-Disposition: Reaction' and 'In-Reply-To:' are
present in a message, these are the semantics; if 'Content-Disposition:
Reaction' is present without 'In-Reply-To:', the semantics are undefined".

Given that MIME can have a hierarchy that includes messages within messages within the body, there is bit of a challenge in how to get the references precise and accurate here.  This language has been reworked a couple of times, but better wording would be... better.  Offerings will be eagerly considered.

In hierarchy terms, the Reaction information needs to be at the same message 'level' as the In-reply-to: that it's associated with.


Section 5

Given the difficulty of conclusively proving a negative, the value of
stating "there is no analysis demonstrating it does" seems minimal.

Matching the minimal threat?

But seriously, if there IS an analysis  I/we don't know of it. Absent that, what else can we say?

Remembering that this is targeting Experimental, I'll suggest that the real purpose of that minimal comment is to highlight the issue and, even more indirectly, to solicit analyses.


    This specification defines a distinct Content-Disposition value, for
    specialized message content.  Processing that handles the content
    differently from other content in the message body might introduce
    vulnerabilities.

The potential for new implementation vulnerabilities when new code is
added for the specialized processing seems clear; it seems there may
also be human-factor vulnerabilities depending on how the information is
displayed, which may be less obvious to some readers and thus worth a
dedicated mention.

Ack.  Here's what I've added:

            <t>This specification defines a distinct Content-Disposition value, for specialized message                 content. Processing that handles the content differently from other content in the message                 body might introduce vulnerabilities. Since this capability is likely to produce new user                 interaction features, that might also produce new social engineering vulnerabilities?</t>

Section 6

    The IANA is request to register the React MIME Content-Disposition
    parameter, per [RFC2183]

     Content-Disposition parameter name:    React

    Allowable values for this parameter:    (none)

At https://www.iana.org/assignments/cont-disp/cont-disp.xhtml I see
distinct registries for "Content Disposition Values" and "Content
Disposition Parameters".
It notably does not have any columns relating what parameters are
allowed for use with a given value.

I hadn't re-read the spec in detail, for this effort, but now that I have, yeah, I suspect a number of things could have been done better in the specification and the administration of it.  I suspect this falls under the cover of "actual practice takes care of such niceties even when the formalities didn't."


My undersatnding is that "React" is intended to be a "content
disposition value" and that no changes to the "content disposition
parameters" registry is to be made (and thus that the last quoted line
serves no purpose for IANA).  Some prose discussion, separate from the
registration, that no parameters are used with the content-disposition
value, would of course be welcome.

I also note that all of the existing entries in the "content disposition
values" registry are written in all lowercase form, but "React" contains
the majuscule 'R'.

Oh my.  That level of attention to detail might be offensive, if it were not so useful.

As in: good catch.  Fixed.


Again, I apologize for having missed the Comments initially. And thanks for making them.

d/

--
Dave Crocker
dcrocker@xxxxxxxxx
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@xxxxxxxxxxxx

--
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