Tim, thanks for your review. John, thanks for your response. I can see how the section references could be a little confusing, but given the context of the surrounding text, I think leaving them as-is is ok. I entered a No Objection ballot.
Alissa > On Mar 11, 2019, at 8:31 PM, John R. Levine <jo...@iecc.com> wrote: > > On Mon, 11 Mar 2019, Tim Evens (tievens) wrote: > >> I should have been more clear. This is NOT specific to HTML/HREF rendering. >> Section references to an RFC without the RFC mentioned is misleading. >> For example: >> " DMARC [RFC7489] defines a policy language that domain owners can >> specify for the domain of the address in a RFC5322.From header. >> >> Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the >> RFC5322.From address domain are to be handled. That section is >> updated to say that all U-labels in the domain are converted to >> A-labels before further processing. Sections 6.7 and 7.1 are >> similarly updated to say that all U-labels in domains being handled >> are converted to A-labels before further processing." > >> The above references Section 6.6.1 (and Sections 6.7 and 7.1), but from >> which RFC(s)? Are these from RFC5322, RFC7489, this draft? This would be >> somewhat more clear if this had mentioned the intended referenced RFC (7489) >> in the same paragraph that the reference is made. For example, In RFC7849, >> Section… > > All of sectioh 6 is about DMARC and the only RFC mentioned in section 6 is > 7489 so I assumed it was clear enough that's what the references are for. I > suppose I could add "of RFC 7489" after each section reference but it seems > awfully pedantic. > >> "In RFC7489, Section 6.6.1 … " is equivalent to "Section 6.6.1 [RFC7489]." >> IMO, authors (in general) should put effort into checking that the various >> renderings meet expectations. If there are incorrect hyperlinks, fix them >> or remove them. The rendering issue is not just HTML, it also effects the >> PDF rendering. > > That really seems like something for the tools team or the RFC editor. The > xref links in the XML are all there, and the stuff you're worried about is > all mechanically created by xml2rfc. > > R's, > John_______________________________________________ > Gen-art mailing list > gen-...@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
