On Wed 2025-06-11 11:12:57 -0700, Alanna Paloma wrote: >> 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. > > ) Please let us know which suggested text is correct for clarity.
The current XML reads: <t>The Author/Change Controller (<xref section="4.5" sectionFormat="of" target="RFC3864"/>) for this entry is the IETF.</t> I think this is acceptable. >>>> ) We have a couple of questions regarding the index. >>>> a. We note that there is a lot of index linking throughout the document. >>>> For it to be most useful, it is ideal that the index points to where the >>>> term is defined, and perhaps other key occurrences, not at each instance >>>> where the term is mentioned. Therefore, may we clean up the index to only >>>> link to definitions and key occurrences? For example, for “Header >>>> Confidentiality Policy” and “HCP”, we suggest only including links to >>>> Section 1.7 and Section 3, Paragraph 2, as these are where the terms are >>>> defined and expanded on. >>>> b. Within instances of “No Header Confidentiality Policy”, only “Header >>>> Confidentiality Policy” is linked. Was the intention to include an index >>>> entry for “No Header Confidentiality Policy” (if yes, we suggest including >>>> only one link to Section 3.2.3 (“No Header Confidentiality Policy”)), or >>>> may we remove the links from these occurrences? >>> DKG? >> >> No opinion. > > ) As Alexey and Bernie do not have any preference, we will await word from > Daniel regarding the questions about the index. Should Daniel have no > preference, we will streamline the index accordingly. As mentioned earlier today, i prefer to simply drop the index entirely. >> 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. > > ) As “Header Fields” applies to “From”, “To”, “Cc”, “Reply-To”, and > “Mail-Followup-To”, we believe the commas in the OLD text are correct. > However, we could update as follows: > > Perhaps: > 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 Header Field, To Header Field, Cc Header Field, Reply-To > Header Field, or Mail-Followup-To Header Field as well as any other signals. I'm fine with either proposed resolution. If i have to choose one, i'd choose the "as well as" variant. >> * 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). > > ) With the hyphen removed, may we further update the text as follows? > > Perhaps: > Although the PEF-2 scheme is only meant to be used between MUAs > compatible with PEF-2, PEF-2 messages may end up at MUAs unaware of PEF-2 > (in which case, they typically render badly). I'm fine with this change. In nit-picky editor mode, i'd typically convert as much as possible from the singular to the plural, which would make this: Although the PEF-2 scheme is only meant to be used between MUAs compatible with PEF-2, a PEF-2 message may end up at an MUA unaware of PEF-2 (in which case, it typically renders badly). I'm OK with either way, with a slight preference for the singular form. > Daniel and Alexey - Note that Bernie has explicitly requested your > input on some of the updates/questions. We have updated per Bernie’s > suggestions, but please review his previous emails and let us know if > further updates are needed. I'll review Bernie's e-mails shortly and send a followup message about each place that he explicitly asked for feedback. --dkg
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
