Dear RFC Editor, Co-authors et al.
Below you can find my 2nd batch of findings in RFC-to-be 9788 while going
through the RFC-Editor changes. Some of the finding are just hints to my
co-authors to look at certain edits that likely need reverting or
adjustments.
Note that those findings / change requests marked with "TBD" need
clarification, either by the RFC Editor or the co-authors (as tagged in
the comments).
All the best,
Bernie
--------------------------
* section 1.2 (minor)
[ TBD (@RFC-Editor): Why was the hyphen removed? My dictionary suggest
using a hyphen in this case. Is this difference in the dictionary used by
the RFC-Editor? ]
OLD:
Producing a signed-only message using this specification is risk free.
NEW:
Producing a signed-only message using this specification is risk-free.
* Section 3.4.2 (minor)
[ TBD: (@RFC-Editor): Are mitigatable and mitigatory exchangeable terms?
To me mitigatable (as originally )sounds more precise here, though unsure
]
OLD
An entry should not be marked as "Recommended" unless it has been
shown to offer confidentiality or privacy improvements over the
status quo and have minimal or mitigatory negative impact on messages
deliverability and security.
NEW:
An entry should not be marked as "Recommended" unless it has been
shown to offer confidentiality or privacy improvements over the
status quo and have minimal or mitigatable negative impact on messages
deliverability and security.
* Section 4.2
[ TBD (@DKG): Is this equivalent to what you want to express here? ]
OLD:
It outputs a pair of lists of (h,v) Header Fields.
NEW:
It produces as output a pair of lists of (h,v) Header Fields.
* Section 4.3.1
[ TBD (@DKG): Is skipping the explicit "if"s appropriate in the pseudo
code? ]
OLD:
6. If the message is encrypted, ct has a parameter hp="cipher", and (h,v)
is not in refouter:
NEW
6. If the message is encrypted, and if ct has a parameter hp="cipher",
and if (h,v) is not in refouter:
---
[Note @DKG: The original did not contain the comma and the 2nd "return" ]
OLD:
i. Return signed-and-encrypted if is_sig_valid is otherwise
encrypted-only.
NEW:
i. Return signed-and-encrypted if is_sig_valid, otherwise return
encrypted-only.
----
[Note @DKG: The original did not contain the comma and the 2nd "return" ]
OLD:
7. Return signed-only if is_sig_valid is otherwise unprotected.
NEW:
7. Return signed-only if is_sig_valid, otherwise return unprotected.
* Section 4.4.1.2.
[ TBD (@RFC-Editor): Suggest to either let all "or"s in (as originally) or
remove all "or"s, e.g. ]
OLD:
* the message has a broken signature,
* the message has a broken signature, or
* the message has a valid signature, but the receiving MUA does not
see any valid binding between the signing certificate and the
addr-spec of the inner From Header Field.
NEW:
* the message has a broken signature
* the message has a broken signature
* the message has a valid signature, but the receiving MUA does not
see any valid binding between the signing certificate and the
addr-spec of the inner From Header Field
* Sections 4.4.2 and Section 4.4.3
[ I would prefer to keep the "and" (as originally), to stress out, that
both conditions must be met. ]
OLD:
* From Header Field Mismatch (as defined in Section 4.4.1.1), and
* No Valid and Correctly Bound Signature (as defined in
Section 4.4.1.2).
NEW:
* From Header Field Mismatch (as defined in Section 4.4.1.1), and
* No Valid and Correctly Bound Signature (as defined in
Section 4.4.1.2).
4.4.4
[ TBD (@RFC-Editor, @DKG, @Alexey): Not sure whether the comma preceding
"or" is correctly set. Shouldn't this be like ]
OLD:
Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may
populate the composer view using a combination of the referenced message's
From, To, Cc, Reply-To, or Mail-Followup-To Header Fields or any other
signals.
NEW:
Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may
populate the composer view using a combination of the referenced message's
From, To, Cc, Reply-To or Mail-Followup-To Header Fields, or any other
signals.
* Section 4.4.5
[ TBD (@Alexey): This original version contained "[...] A-label form is
described [...]". I guess you menat "as described" ]
OLD:
If it does, it MUST be converted to the A-label form, which is described
in [RFC5891].
NEW:
If it does, it MUST be converted to the A-label form as described in
[RFC5891].
* Section 4.6
OLD:
In another example, Section 6.2 notes that the value of the Reply-To field
can influence the draft reply message.
NEW:
In another example, Section 6.2 notes that the value of the Reply-To
Header Field can influence the draft reply message.
* Section 5.2.2
[ Note: The Legacy Dislay Element may consist of several lines, correct as
it was originally ]
OLD:
Note that the Legacy Display Elements (the lines beginning with
Subject: and Cc:) are part of the body of the MIME part in question.
NEW:
Note that the Legacy Display Element (the lines beginning with
Subject: and Cc:) are part of the body of the MIME part in question.
* Section 6.1
[Note: slight change in semantics using the hyphen, better as it was
originally]
OLD:
If the Header Field's value is unchanged, the composing MUA regenerates
the Header Field using the Header Fields that had been on the outside of
the original message at sending time.
NEW:
If the Header Field's value is unchanged, the composing MUA re-generates
the Header Field using the Header Fields that had been on the outside of
the original message at sending time.
* Section 6.1.1
@DKG: Please verify that the edits have not changed the semantics in the
paragraphe "[...] * A built-in MUA respond [...]
@DKG: I am almost certain that the edits around "8. Return a new HCP from
confmap that tests whether [...]" need to be reverted in part. Please
check!
* Section 6.2
@DKG, @Alexey: "Replay" was changed to "Relay". I think this should be
reverted. Any thought?
* Section 7.1
OLD:
An MUA that receives a message with Header Protection that contains these
Header Fields in the unprotected section and that has reason to believe
the message is coming through a mailing list MAY decide to render them to
the user (explicitly or implicitly) even though they are not protected.
NEW:
An MUA that receives a message with Header Protection that contains these
Header Fields in the unprotected Header Section and that has reason to
believe the message is coming through a mailing list MAY decide to render
them to the user (explicitly or implicitly) even though they are not
protected.
* Section 11.2.2
@DKG, @Alexey: Not sure whether or not the edits around "mailbox" are
correct. Any thoughts?
* Section 12.3
@DKG, @Alexey: The following sentence has not been added to the IANA
registry as requested:
"Note that during IETF Review, the designated expert must be consulted.
Guidance for the designated expert can be found in Section 3.4.2."
Are we fine with this?
* Appendix F.2. (minor)
[ Note: The TXT version has the line break at an odd place. Suggest to
remove the introduced hyphen.]
OLD:
Although the PEF-2 scheme is only meant to be used between PEF-
2-compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2
(in which case, they typically render badly).
NEW:
Although the PEF-2 scheme is only meant to be used between PEF-2
compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2
(in which case, they typically render badly).
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
