IANA, Please update https://www.iana.org/assignments/bundle/bundle.xhtml#admin-record-types as follows, based on the author's reply pasted below. This corresponds to Table 1 of RFC-to-be 9713 (https://www.rfc-editor.org/authors/rfc9713.txt).
Remove "6,7" from the rows from value 3 and 5-15. In a separate mail, I have asked the author to confirm that there is no change to this row: | 7 | 16 - | Unassigned | | | | 64383 | | | Thank you. RFC Editor/ar On Jan 10, 2025, at 12:36 PM, Brian Sipos <brian.sipos+i...@gmail.com> wrote: > 6) I'm trying to find some example of similar overloaded code point tables > outside of the Bundle Protocol registry group, but failing to do so. There is > no implication that assignments in that range need to apply to both version 6 > and 7. Other tables in the Bundle Protocol registry group leave the version > column empty for the unassigned values, so it's probably best to do so here > also. > > Table 1 > OLD: > | 6,7 | 3 | Unassigned | | > | 6,7 | 5 to 15 | Unassigned | | > NEW: > | | 3 | Unassigned | | > | | 5 to 15 | Unassigned | | > > Related to this table, I see that there have been some edits to replace "X to > Y" numbering with "X-Y". Is this the consistent way to indicate this in > registries? I was trying to avoid using the hyphen to not confuse it with a > negative sign, but whatever is consistent is the right way. On Jan 6, 2025, at 11:47 PM, rfc-edi...@rfc-editor.org wrote: >> 6) <!-- [rfced] Because values 3 and 5-15 are unassigned, is it correct for >> the Bundle Protocol Versions to be noted as 6,7? Does this imply that 6 >> and 7 must apply to future assignments of those values (i.e., 6,7 apply to >> unassigned values defined by BPv6, and 7 (only) applies to all other future >> assignments as values 16+ are defined for BPv7)? >> >>> From Table 1: >> | 6,7 | 3 | Unassigned | | >> | 6,7 | 5 to 15 | Unassigned | | >> --> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
