On 1/8/25 21:30, Brotman, Alex wrote:
> If you think this is ready, I will merge a PR and release a new version after 
> that.

I think it's almost ready. I have one or two points I'd like to fix, but
I haven't worked on it since the email you responded to was written.

The biggest issue, one that I think need author guidance, is which of
the table formats to use. There have been many suggestions on the layout
of the tables, specially for the column that shows the number of allowed
elements.

See my previous mail to see the tables in all their glory, but it boils
down to the space used:

   +==============+===+=============================+
   | Element name | # | Content                     |
   +==============+===+=============================+

The short column name is beneficial because it leaves more space for the
content column.

The value of the '#' column may be:

" " (empty): OPTIONAL element
"R": REQUIRED element
"*": 0 or more elements
"+": 1 or more elements

"*" and "+" can be understood like in regexp syntax.


   +==============+==========+=============================+
   | Element name | Required | Content                     |
   +==============+==========+=============================+

   +==============+=======+=============================+
   | Element name | Req'd | Content                     |
   +==============+=======+=============================+

The name is more explicit and wider. The cost is one or two pages extra
compared to the "#" alternative above.

For these two, the value of the 'Required' column may be:

No:  OPTIONAL
Yes: REQUIRED
No *: 0 or more elements
Yes *: 1 or more elements

I also wrote about using "0..n" and "1..n" as synonyms for "No *" and
"Yes *", but I think that is less clear.


If we do not want to use notation to signal an unbounded amount of
elements, we can add something like the following immediately after the
table:

  The maximum number of "foobar" elements is unbounded.

I think it's time for the draft author to make a decision, and I'll
adjust accordingly.


Daniel K.

_______________________________________________
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

Reply via email to