Hi, The "Bundle Protocol Version" field is now blank for values 3 and 5-15 in the Bundle Administrative Record Types registry:
https://www.iana.org/assignments/bundle/bundle.xhtml#admin-record-types (I tried checking against https://www.rfc-editor.org/authors/rfc9713.txt, but got a 404.) thanks, Amanda On Fri Jan 17 21:18:21 2025, aru...@staff.rfc-editor.org wrote: > 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
