Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <alpine.OSX.2.21.1903120927080.49371@ary.local>
Date: Wed, 10 Apr 2019 12:01:11 -0400
Cc: Tim Wicinski <tjw.ietf@gmail.com>, Ben Campbell <ben@nostrum.com>,
 Adam Roach <adam@nostrum.com>, "ietf@ietf.org" <ietf@ietf.org>,
 Alexey Melnikov <aamelnikov@fastmail.fm>,
 Tim Evens via Datatracker <noreply@ietf.org>,
 "gen-art@ietf.org" <gen-art@ietf.org>, "dmarc@ietf.org" <dmarc@ietf.org>,
 Murray Kucherawy <superuser@gmail.com>,
 Barry Leiba <barryleiba@computer.org>, Kurt Andersen <kurta@drkurt.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7926C13-0C4E-440D-B128-4A955188A420@cooperw.in>
References: <155234487991.23094.14124317288389045798@ietfa.amsl.com>
 <CALaySJK9h=xs4ZcmkTKf1ffpCv4ayhQ_NqPWzHGg17oRLrizNQ@mail.gmail.com>
 <53F5AD4A-BCE9-4E00-A982-4365BBD9ACA8@cisco.com>
 <alpine.OSX.2.21.1903120927080.49371@ary.local>
To: "John R. Levine" <johnl@iecc.com>,
 "Tim Evens (tievens)" <tievens@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/2HrkLACuWflkzitjjMnU3OmHJiY>
Subject: Re: [Gen-art] [taugh.com-standards] Re: Genart last call review of
 draft-ietf-dmarc-eaiauth-03
Precedence: list

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@iecc.com> wrote:
>=20
> On Mon, 11 Mar 2019, Tim Evens (tievens) wrote:
>=20
>> 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.=46rom header.
>>=20
>> Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the
>> RFC5322.=46rom 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."
>=20
>> 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=E2=80=A6
>=20
> 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.
>=20
>> "In RFC7489, Section 6.6.1 =E2=80=A6 "  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.
>=20
> 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.
>=20
> R's,
> John_______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art