On 5/15/25 8:00 AM, Paul Kyzivat wrote: > On 5/15/25 9:21 AM, Marc Petit-Huguenin wrote: > ... >> 2. for each document in the set, strip all the non-normative parts. >> 3. print all the modified documents in TEXT format. > ... >> But step 2 is unfortunately not as simple, as deciding which parts are >> normative and which are just informative have to be done currently using >> heuristics, at least for RFCs. So my suggestion would be to modify the >> RFCXML format to add a flag on <t> elements (and maybe <table> elements) to >> clearly indicate which ones are normative (i.e., required to implement an >> interoperable piece of software) and which ones are not. >> >> Note that solving the problem of having that flag rendered into the derived >> formats is not part of this request. > > 1) This sort of tagging would need to be reviewed. That can't reasonably > happen unless it is rendered in the derived formats that are used by > reviewers.
Sure. It's just that I do not care how it is formatted. > > 2) How would you distinguish between MUST/SHOULD/MAY distinctions? You do not need to. Any paragraph contains a BCP 14 keyword is by definition a normative paragraph. > > 3) How would you deal with something like: > > "Each message MUST conform to the syntax specified by ABNF > rule 'Message' defined in Appendix Z." That would be trying to make a normative paragraph referencing an informative section (because appendixes should always be informative). Hopefully the IESG or the RFC-Editor will stop that. -- Marc Petit-Huguenin Email: [email protected] Blog: https://medium.com/@petithug Profile: https://www.linkedin.com/in/petithug
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
