Fix: #1941. Editorial alignments

[ioggstream]

This PR

• same boilerplate text for C-Digest and R-Digest
• avoid ABNF in favor of Types
• representation-data -> representation data
• representatio-data-digest -> digests (clarified in Notational Convetions);
• integrity fields -> Integrity fields (@LPardue let me know if you meant it lowercase, it's ok to me in any way);
• digest algorithm -> hashing algorithm,

Note: it'd be cool if we could write something like

~~~ abnf
R-Digest = sf-dictionary
member-value = sf-binary

but it's ok anyway

[LPardue]

Thanks for these.

I'm still unsure of the best way to reference structured fields things. I've seen all kinds of permutations across drafts, so I sent an email to the list to see if anyone has an opinion we might be able to align to. I agree that being able to express the type constraints in ABNF would be nice but I don't think that's standard and might be a step too far.

[LPardue]

Dictionaries already describe how to treat duplicate entries. So we probably need a separate issue to fix up this paragraph.

[ioggstream]

Once a field is signed, even a compliant mangling invalidates the signature. I see this line as a simple advice to the users.

[LPardue]

This is something I sidestepped during the initial change to SF. The SF grammar allows parameters, so member-values can have them. The SF says

   Both Items and Inner Lists allow parameters as an extensibility
   mechanism; this means that values can later be extended to
   accommodate more information, if need be.  To preserve forward
   compatibility, field specifications are discouraged from defining the
   presence of an unrecognized parameter as an error condition.

When updating Digest we decided parameters could be a security problem. If we want prohibit the use of SF parameters, then we need some form of normative text to state that and probably justify why. I'd suggest doing that in a separate paragraph.

[LPardue]

Furthermore, if we move the parameter discussion elsewhere, then we can get rid of the list format and use a prose style similar to what's already there.

[ioggstream]

@LPardue I added a paragraph in the security consideration.

[LPardue]

This point is not important enough to be the first one, it's a distraction to most readers.

I would strongly prefer we use prose style to discuss keys and values and punt the parameter discussion to a following paragraph

[ioggstream]

@LPardue as a non-native speaker, I just feel prose a bit harder to read, but sure! Feel free to edit this PR :)

[LPardue]

Furthermore, prohibiting parameters suffers can lead to the same fate of validation DoS.

So the text that discusses normative behaviour of parameters has to be more nuanced than a single line.

[LPardue]

Understood but it's likely that such an editorial comment would come up during our later review anyway. I'll take a go and implementing my suggestion.

[ioggstream]

I'll take a go and implementing my suggestion.

🚀

[ioggstream]

Parameters will be managed in another PR

[ioggstream]

@LPardue I deferred parameters to another PR. After you refactor the list as prose, feel free to merge :)

[LPardue]

Thanks @ioggstream, theres a lot of good fixes in here and the effort is appreciated.