This page is a compilation of formal public feedback received so far. See Feedback for further information on this issue, how to discuss it, and how to provide feedback.
Date/Time: Tue Jun 30 14:18:36 CDT 2015
Name: Doug Ewell
Report Type: Public Review Issue
Opt Subject: PRI #299
I support this proposal. I have the following questions: 1. The existing RIS-based flag mechanism is based on ISO 3166-1 (TUS 7.0 §22.10). In this proposal, "valid" tag sequences would instead be determined by CLDR data and LDML specification. Is there any precedent for CLDR to define the validity of Unicode character sequences? 2. What is the policy on generating flag tags with deprecated unicode_region_subtag or unicode_subdivision_subtag values, such as "[flag]UK"? How "discouraged" would such a tag be? Should tools allow users to create such a tag? 3. The subdivisions.xml file contains a "subtype" hierarchy, reflecting the "parent subdivision" relationship in ISO 3166-2. So region 'FR' contains subdivision 'J' (Île-de-France), which itself contains subdivision '75' (Paris). Is there any significance to the "subtype" hierarchy as far as flag tags are concerned, or are "[flag]FRJ" and "[flag]FR75" equally valid? 4. The entry for "001" in subdivisions.xml contains each of the two-letter codes for regions (countries) that have their own subdivisions. This is less than the set of all regions; for example, Anguilla (AI) does not have ISO 3166-2 subdivisions and so is not listed. This implies that a tag like "[flag]001US" is valid (and equivalent to "US" spelled with RIS, which is preferred) but "[flag]001AI" is not valid. Is this intended? If not, can it be clarified? 5. Will any preliminary examples of CLDR 4-character subdivision codes be made available before any such codes are actually assigned?
Date/Time: Tue Jun 30 14:40:22 CDT 2015
Name: Doug Ewell
Report Type: Public Review Issue
Opt Subject: PRI #299
The PRI #299 mechanism is clearly and intentionally oriented toward representing flags of well-defined geopolitical entities. Any proposal to extend the mechanism to cover the many other types of flags -- for historical regions, NGOs, maritime, sports, or social or political causes -- must be systematic and well-planned, not ad-hoc or haphazard, to assure interoperability and extensibility. The documentation for the PRI #299 mechanism should state clearly that (e.g.) the Confederate battle flag, the Olympic flag, the Esperanto flag, the LGBT rainbow flag, and the naval flags used to spell out "ENGLAND EXPECTS" can be represented only via a proper extension to the mechanism, not by ad-hoc means such as the use of unassigned or private-use combinations. This is at least as important as ensuring the stable coding of geopolitical flags.
Date/Time: Thu Jul 2 10:05:48 CDT 2015
Name: Doug Ewell
Report Type: Public Review Issue
Opt Subject: PRI #299
6. What is the policy on generating flag tags with unicode_region_subtag values corresponding to private-use BCP 47 subtags, other than those given special semantics by CLDR? Are they invalid or merely discouraged? Should tools allow users to create such a tag? Is there any provision for a "private agreement," similar to that defined in Unicode for PUA usage?
Date/Time: Thu Jul 2 16:17:17 CDT 2015
Name: Leo Broukhis
Report Type: Public Review Issue
Opt Subject: PRI #299
Using default-ignorable characters results in an undesirable fallback behavior: a U+1F3F3 WAVING WHITE FLAG by itself is not informative. To quote, "This base character is a visible spacing character that suggests a flag, so that implementations that do not support the TAG characters have an indication that a flag is present." However, whenever a flag is used, the primary intention is to indicate the entity or concept represented by a flag, therefore the preferred fallback behavior would be to lose the flag form while keeping the identifying information visible. This is better achieved with a scheme using visible characters, like already existing regional indicator symbols.
Date/Time: Thu Jul 2 17:24:45 CDT 2015
Name: Ken Whistler
Report Type: Public Review Issue
Opt Subject: PRI #299: a registry mechanism
I suggest that the correct way to incorporate a generalized extension mechanism for the PRI #299 scheme of use of tag characters together with CLDR-defined unicode_region_subtags and unicode_subdivision_subtags is as follows: Define the private use region subtag "XF" as meaning flag pictograph defined in the Unicode Flag Pictograph Registry. (UFPR) Use a 4 digit number, starting from 0001 and extending (in principle) to 9999 as a unique identifier for registered entries in the UFPR. (Should 10,000 entries prove insufficient, this scheme could later be extended almost indefinitely as A000..A999, B000..B999, etc.) Use the same syntax as for the regular region/subdivision tag identification of particular flags. So, e.g., for UFPR registration number 0001, a corresponding full tag sequence would be: <Base, TAG-X, TAG-F, TAG-0, TAG-0, TAG-0, TAG-1> This would be syntactically completely consistent with the rest of the proposed mechanism. Semantically, it would require only knowing that "XF" branches out to the UFPR for validation, instead of to the CLDR tables of valid region/(contained)subdivision pairs. In all other respects, including fallback to display of the sequence simply by the glyph for the base flag symbol, this mechanism would behave identically. To support the UFPR registry, initiate a new UTS, structured along the lines of UTS #37, which currently defines the IVD and its maintenance procedures. The new UTS would define the applicable procedures for submission and review of a flag pictograph for registration. It should include fairly strict criteria that would guarantee non-overlap with flag pictographs already representable by the RIS pairs or proposed tag extension mechanism with region/subdivision tags, and to prevent against nuisance, trivial, or duplicate registrations. It should also have strict requirements for clear submission of a specific representative color glyph (with unencumbered IPR) and clear identification and intended use. Mass submissions by vague reference to external sources would not be allowed, although presumably the registrar could work out streamlined procedures for bona fide submissions of well-defined sets of related flag pictographs -- e.g. a set of maritime flags, signal flags, or such. Other details would need to be worked out, of course, but I envision a fairly open set of criteria, whereby the registrar would not block registrations based on political, ideological, religious, or other potential biases, except insofar as a proposed registration might clearly run into national or international legal issues (think Nazi flag), or where unencumbered IPR was not demonstrable (think flags for corporations). To be useful for interchange purposes, the actual UFPR registry would have to be easily accessible online, with its content consisting at a minimum of distinct records showing the registration number, a clear and distinct representative color pictograph, and unambiguous identifying metadata for the registration. It would *not*, however, be a glyph *service*. Implementers and vendors would need to choose which entries they would support in practice, and would be responsible for designing and making available the actual flag pictographs in fonts they would use, consistent with any such pictographs they implement for the other standard (non-registry) mechanisms.
Date/Time: Mon Jul 20 17:19:11 CDT 2015
Name: Doug Ewell
Report Type: Public Review Issue
Opt Subject: PRI #299: base character
In response to objections raised on the public mailing list, I suggest that the exact appearance of the base character (white vs. black flag, still vs. waving, rectangular vs. triangular, etc.) will not make a significant difference and should not, by itself, cause this tagging mechanism to be delayed until a new character can be encoded, in Unicode 9.0 at the earliest. In particular, distinct base characters should not be used to distinguish a still flag from a waving flag, because some fonts already show the existing RIS-based flags as waving while others already show them as still, and because there is little or no semantic difference for country and subdivision flags such as those under discussion here.
Feedback below this line was received after closure of the PRI.
Date/Time: Thu Oct 1 10:08:34 CDT 2015
Name: Tim Larson
Report Type: Public Review Issue
Opt Subject: PRI 299
Some general agreement with Leo Broukhis' comment from July 2. Why not use the Regional Indicator Symbols as base characters, followed by tag characters for the subregion? Then if you have UStx or FRe but can't display this properly as Texas or Brittany flags, you should see American and French flags (which seems better than a completely generic flag), or at least "US" and "FR". It seems silly to have developed RIS and then NOT use them when you're trying to display a symbol for a region.
Date/Time: Tue Oct 6 05:08:20 CDT 2015
Name: Ian Perryman
Report Type: Public Review Issue
Opt Subject: Unacceptable regionalisation
Reference PRI 299 In the detailed technical responses received and published the emphasis for the flags of the countries in the UK are based on the prefix GB followed by a regional sub code. e.g.GB-SCT for Scotland and GB-WLS for Wales. This may well be a sufficient technical answer but ignores why people want their own flag e.g. the Saltire for Scotland or the Draig Goch for Wales. Firstly and foremost the people of Scotland and Wales do not regard themselves as belonging to a region but as citizens of a distinct country. In recognition of which the recent .scot, .wales and .cymru domain extensions were recently issued. Many people would therefore find the syntax GB - sub section Scotland or subsection Wales offensive. In Wales you also have the additional problem that Wales has, in its own widely spoken language (Welsh), a different name for the country i.e. Cymru. To tell Welsh speakers that their country is now known internationally as Great Britain subsection Wales (all in English) is a gratuitous insult. I am sure that the same local language issue would apply to other areas dismissively referred to as 'regions' in your correspondence. I would urge you to consider a different format.