On Sat 2025-05-24 02:09:45 +0200, Bernie Hoeneisen wrote: >> 8) <!--[rfced] May we update "non-encrypted" to "unencrypted"? >> >> Original: >> A sending implementation MUST NOT produce a Cryptographic Payload >> with parameter hp="cipher" for a non-encrypted message (that is, >> where none of the Cryptographic Layers in the Cryptographic Envelope >> of the message provide encryption). >> >> Perhaps: >> A sending implementation MUST NOT produce a Cryptographic Payload >> with parameter hp="cipher" for an unencrypted message (that is, >> where none of the Cryptographic Layers in the Cryptographic Envelope >> of the message provide encryption). >> --> > > No objection. > > @DKG?
Yes, I agree to this change. (it is already in the current XML) >> 14) <!--[rfced] To improve readability, may we update the phrasing of "may >> not >> expect to be injected by their MUA" as follows? >> >> Original: >> This can be >> especially problematic for Header Fields that are not user-facing, >> which the sender may not expect to be injected by their MUA. >> >> Perhaps: >> This can be >> especially problematic for Header Fields that are not user-facing; >> the sender may not expect these Header Fields to be injected by their MUA. >> --> > > Maybe replace "these" by "such" in your suggestion: > > This can be > especially problematic for Header Fields that are not user-facing; > the sender may not expect such Header Fields to be injected by their MUA. > > @DKG? I'm fine with this change (it is already in the current XML) >> 15) <!--[rfced] May we update "genericize" to "generalize"? >> >> Original: >> So even if an >> ambitious HCP opts to remove the human-readable part from any From >> Header Field, and to standardize/genericize the local part of the >> From address, the domain will still leak. >> >> Perhaps: >> So even if an >> ambitious HCP opts to remove the human-readable part from any From >> Header Field, and to standardize/generalize the local part of the >> From address, the domain will still leak. >> --> > > No opinion. > @DKG? https://en.wiktionary.org/wiki/genericize defines genericize as "to make generic". If we want to avoid this neologism, we could try a stronger rewrite: So even if an ambitious HCP opts to remove the human-readable part from any From Header Field, and to transform the local part of the From address to a standard or generic form, the domain will still leak. >> 16) <!--[rfced] We have included some specific questions about the IANA >> text below. In addition to responding to those questions, please >> review all of the IANA-related updates carefully and let us know >> if any further updates are needed. >> >> a) In Section 12.1, does the "Author/Change Controller" information >> only apply to the "HP-Outer" registration? If so, may we update the >> text below to reflect "this entry" (instead of "these two entries") >> as shown in option A? Or if it also applies to the "Content-Type" >> registration, may we move it to the end of Section 12.2 and update >> the text as shown in option B? >> >> Original: >> The Author/Change Controller of these two entries (Section 4.5 of >> [RFC3864]) should be the IETF itself. >> >> Perhaps A: >> The Author/Change Controller (Section 4.5 of [RFC3864]) for this >> entry is the IETF itself. >> >> Perhaps B: >> The Author/Change Controller (Section 4.5 of [RFC3864]) >> for the HP-Outer and Content-Type Header Field name >> registrations is the IETF itself. > > To me Option A appears to be the better. (History: At some ealier stage we > had two Header Fields for registration, thus this is most likley a > leftover.) > > Furthermore, I suggest to remove the word "itself". > > @DKG @Alexey ? I agree with Bernie here. I think the current state of the XML draft is in good shape (as mentioned in my previous e-mail message) >> 17) <!--[rfced] What does "the draft" refer to in the sentence below? >> Should this be updated to "the draft message"? Note that there are >> other occurrences like the example listed below that are used throughout >> the appendices of this document. >> >> Original: >> It uses the Header Protection scheme from the draft. >> >> Perhaps: >> It uses the Header Protection scheme from the draft message. >> --> > > I guess you are refering to the occurances in Appendix C. > To my understanding those refer to this document (RFC-to-be 9788). > @DKG? > > Note: This text is also part of the autogenerated testvectors (i.e. those > in the grey boxes) in Appedix C, which MUST NOT be changed. This is due to > signature and encryption, i.e. signature and decryption will fail for > those using the test vectors, if edited. (If we wanted to change this, DKG > would need to reproduce the test vectors.) This is part of my intended followup about the test vectors. I won't tackle it in this message. >> 19) <!-- [rfced] We have some questions/comments regarding artwork and >> sourcecode: >> >> a) Please review each artwork element and let us know if any should be marked >> as sourcecode (or another element) instead. > > How can we find out which artwork element is marked with what? > >> b) Some artwork elements are marked as type "ascii-art" while others are >> not. Please review and let us know if there are any artwork elements you >> would >> like to have marked as "ascii-art". > > The only artworks I am aware of are the 3 figures in Appendix D. > >> c) Since the sourcecode type "text/x-hcp" is not part of the list at >> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>, >> may we update to sourcecode type "pseudocode"? Note that it is also >> acceptable to leave the "type" attribute not set. >> --> > > No opinion. > @DKG? This is part of my intended followup about artwork and sourcecode. I won't tackle it in this message. >> 22) <!-- [rfced] Please review whether any of the notes in this document >> should be in the <aside> element. It is defined as "a container for >> content that is semantically less important or tangential to the >> content that surrounds it" >> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >> --> > > I am not aware of such notes. > @DKG @Alexey? I've already observed that i don't think any of the "Note"s need to be placed in an <aside>. >> Method Signature vs. Method signature > > "Method signature" appears more sensible to me. > @DKG? I agree with "Method signature", and that is reflected in the current XML. >> Non-Structural Header Field vs. non-structural Header Field > > We define "Structural Header Field" in section 1.7 (Terms) refering to > RFC-to-be 9787. However, Non-Structural Header Field is not explicitely > defined in neither of the documents. Therfore, I suggest: > > 1) Use "Non-Structural Header Field" throughout the document > > 2) Add a brief definition for "Non-Structural Header Field" to RFC-to-be > 9787, e.g. "Header Field that is not a Structural Header Field" (or alike). > > 3) add a definition for "Non-Structural Header Field" to Section 1.7 (as > reference to RFC 9787 similar as existing for "Structural Header Field"). > > @DKG, @Alexey? I think we've gone ahead with steps 1 and 2, and we didn't need to do anything for 3. I think the current state of the XML is good. >> Outer Header Section vs. outer Header Section > > We use this quite ofter without Defining it properly. Therefore, I > suggest: > > 1) Use "Outer Header Section" throughout the document > > 2) Add a definition to section 1.7, e.g. "The unprotected Header Section > that MTAs and MUAs unaware of Header Protection treat as the Header > Section of the Message." (or alike) > > @DKG @Alexey? I think we've done both of these things. the current text of the XML is good. >> d) Please review instances of the term "NULL" used in this document. >> Should they instead be "NUL" (that is, referring to the specific >> ASCII control code), "null character", or just "null"? > > I am not aware that we use "NUL" or "null character" in relation with > ASCII. > @DKG? I agree with Bernie here. the current use of "null" in the XML is good, and as expected. Thanks for having tracked all these questions down, Bernie! --dkg
signature.asc
Description: PGP signature
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
