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…

Natural language interpolation is challenging.  I agree that there are 
different ways to reference something that may or may not work with the current 
renderings. For example:

"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.

I believe the author is putting in effort to correctly reference the sections, 
but it's not consistent.  The draft does have many references to sections that 
correctly link.

Take for example:


"Section 4.3 of [RFC7208] states
   that all IDNs in an SPF DNS record MUST be A-labels; this rule is
   unchanged since any SPF record can be used to authorize either EAI or
   conventional mail.
"

Thanks,
Tim






On 3/11/19, 4:02 PM, "Gen-art on behalf of Barry Leiba" 
<[email protected]<mailto:[email protected]> on behalf of 
[email protected]<mailto:[email protected]>> wrote:

Thanks for the review, Tim.

The html rendering issues are for the RFC editor to deal with, and not in the 
scope of the draft editors.

Barry

On Tue, Mar 12, 2019 at 7:54 AM Tim Evens via Datatracker 
<[email protected]<mailto:[email protected]>> wrote:
Reviewer: Tim Evens
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dmarc-eaiauth-??
Reviewer: Tim Evens
Review Date: 2019-03-11
IETF LC End Date: 2019-03-14
IESG Telechat date: Not scheduled for a telechat

Summary:
Ready with nits.

Major issues: None

Minor issues: None

Nits/editorial comments:

Throughout the draft, section references (html rendering) does not correctly
HREF the RFC and section.  For example, page-5 Section 6 has a reference to
section 6.6.1 of RFC7489, but the HTML rendering HREF links to this draft
instead of correctly linking to RFC7489 Section 6.6.1. Ideally the references
should link correctly, for example on page-3 Section 4 with "Section 3 of
[RFC7208]."

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to