As stated previously, I've made all stated changes, with the exception of the below, for further discussion:
On Thu, Aug 2, 2018 at 6:43 AM, Dave Crocker <dcroc...@gmail.com> wrote: > 4. Protocol Elements >> > > > I keep thinking that it would help to have some summary text, possibly > with a figure, that shows the role of individual header fields and sets of > them. > > My first inclination is to suggest putting it here, but perhaps it would > actually be better to have it at the /end/ of this section, after each > component has been defined. > > (I'd offer some candidate text/figure, but I am not sure I have a solid > enough sense of the details.) > This is a good suggestion, but form is unclear. Any guidance from the working group would be appreciated. > To preserve the ability to verify the integrity of a message, the >> > signature of the AMS header field SHOULD include any DKIM-Signature >> header fields already present in the message. >> > > Arguably, including it/them does NOT alter integrity validation. i suspect > /ever/. At the least, be explicit about /what/ integrity is being maintain. > > That is, the dkim signature provides a specific kind of integrity. If it > validates, that integrity is proved. If it doesn't, it isn't. covering it > by ARC doesn't affect either outcome. > This feels more like guidance than a requirement for interoperability. Should it be moved into ARC-USAGE, or further clarified the way suggested? > _INFORMATIONAL:_ The upper limit of 50 was picked based on some > > initial observations reported by early working group members with a >> safety margin multiple added on top to support the vast majority of >> all intermediary mail flows. >> > > Rather than citing a wg process, document the technical, administrative > and/or operation concerns, benefits, etc. that justify the choice. > I think this is OK for an Experimental draft, especially with the callout in 11.3.2. For standards track clarification will be essential. > Valid ARC Sets MUST have exactly one instance of each ARC Header >> field (AAR, AMS, and AS) for a given instance value and signing >> algorithm. >> >> _INFORMATIONAL:_ Initial development of ARC is only being done with a >> single allowed signing algorithm, but parallel work in the DCRUP >> working group is expanding that. For handling multiple signing >> algorithms, see [ARC-MULTI]. >> > > As a rule, RFCs should not refer to parallel activities, since the > reference is soon to become stale and wrong. > > If additional signing algorithms are anticipated -- and of course they > should be -- then define a means for extending what is permitted, noting > that the initial algorithm is provided to ensure basic, initial > interoperability. > Understood. Earlier consensus was that this is fine for the experiment (as algorithm rotation is irrelevant if the experiment fails), and that requirements for rotation would be part of a final standards track document. Should these INFORMATIONAL items just be ripped out in the meantime?
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
