John C Klensin wrote: > In a situation like this, if the community leaves the IESG to > make this sort of decision without significant community > input, then the community deserves whatever the IESG does, > including coin-tossing. If people care, they should say so > clearly enough that the IESG's role is to interpret community > input, not to make things up because no one (besides some > soreheads like me) is saying anything. It's not that nobody but you said anything about it, in fact it's the only case of a potential "rough consensus" not covered by a half dozen LTRU tickets. What Addison said is IMHO correct, 3066bis must replace 3066, they can't coexist. One of the main design goals was backwards compatiility. Any solution designed to exist in parallel with 3066 would be completely different, because it's not forced to be backwards compatible. For starters there won't be a kludge like "Suppress-Script" in that hypothetical solution. Most probably we agree so far, and then the question of BCP vs. standards track is among other things a matter of taste. It's apparently a "feature" of 2026 that the IESG decides about the status - in the usual sense of "your feature is my bug (and v.v.)", so all we can do is offer some opinions. If you'd press the WG for some kind of consensus about this I'd bet that you'd get "BCP with an option for the IESG to say PS", exactly as Scott (= the AD, the Proto-shepherd avoided that issue) stated it. With some more or less convincing reasons. And finally it's not up to the author / WG / Chair / community to decide about the status. Unfortunately in the case of some individual submissions, this "experimental" loophole to bypass a proper "IETF last call" as seen for SPF and SID was "wrong" (a 2234bis "wrong", so that's as bad as 32 ordinary wrongs :-) But for ltru-registry there was a "last call", and I think the IESG knows that some (not only you) prefer PS instead of BCP for 3066bis - under the conditions listed by Addison. > FWIW, that split in the BCP series is already covered in > draft-ietf-newtrk-repurposing-isd. Thanks for info, added to my "I-D collection" - admittedly I'm lost in this one-step / two-step / add-XML-step netwrk-maze. > Perhaps my imagination is worse than yours, but I can easily > imagine "numeric country codes prohibited" or "alpha-2 > country codes prohibited" (note that matching the two > requires large tables that are not, as far as I know, freely > available for free and that change). In that case your imagination is worse tha mine. The _actual_ lists are freely available, e.g. the alpha-2 country codes: http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html?printable=true#AA It's unnecessary to match these lists. All details about the registration of region codes are specified in 3066bis. Forward, sideward, backward, 3166 screws up, 3166 out of sync with UN, everything, we discussed this for months. It was the reason why I was interested in this WG. It makes no sense to exclude all numeric country codes, that's the "escape hatch" if 3166 is forced to reuse an aplha-2 code (examples: GE, SK, CS), because 3066bis tags are persistent (unlike 3066 tags). Maybe you could exclude the UN "macro-regions" (~ continents), you could as well exclude some languages or scripts, or all variants. If you do so, fine, but that doesn't affect the registry. There's one thing where getting _free_ lists could be tricky: old region codes. OTOH precisely that issue is addressed by the registry with its persistent subtags, you don't need any old UN or 3166-lists to determine what 3066bis subtags mean (unlike 3066 tags). > I can also imagine "script required" or "region, if present, > ignored" or a number of other variations and profiles. Yes, the first case was also in my shorter list. If you take language + script + region as three "dimensions", then the language is required (using the langtag registry in other contexts could be a bad plan, it's not designed to be a say region registry, and for a script registry you can also use the ISO standard). That leaves two dimensions where you could say "ignored" or "required". Better don't consider "variant" as an independent fourth dimension, it's not, generally it has a "Prefix". All in all you'd get about four potential "profiles": I-I, I-R, R-I, and R-R (I = ignored. R = required). The concept of regions in 3066 and 3066bis is so clumsy that I can't imagine any serious case of R. That reduces the profiles to I-I + R-I (= my "to script or not to script"), or maybe I-I, R-I, I-?, and R-I (? = region allowed). >> Maybe we could mention this in a note about the extension >> registries. Also as a hint for the future DS^W3066ter. > "Add later" is much more plausible, at least formally, with > a Proposed Standard than it is with a BCP. Add Jefsey and we're three. and that's not much, bye, Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf