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 <johnl@xxxxxxxx> 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-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
