1). In Section 3.5:
The ietf-languages list is an open list and can be joined by sending a request to <ietf-languages-request at iana.org>. The list can be hosted by IANA or by any third party at the request of IESG.
It is not clear how the "third party" option would interact with IANA managing the registry. The lists either have to be managed by IANA on an IANA system or have to be routed through IANA systems. If there is a desire to be able to delegate handling of this mailing list to a third party, then perhaps the mailing list should be in a separate subdomain, e.g. ietf-languages at languages.iana.org.
I think this needs to be discussed further with IANA. 2). In Section 3.1.1:
Each field can be considered a single, logical line of characters. Each field contains a 'field-name' and a 'field-body'. These are separated by a 'field-separator'. The field-separator is a COLON character (%x3A) plus any surrounding whitespace. Each field is terminated by the newline sequence CRLF. The text in each field MUST be in Unicode Normalization Form C (NFC).
You should consider referencing RFC 5198 here.3). Registry format: IANA is switching its registries to XML. The WG should consider switching the format. Alternatively 4646bis should be updated to specify reasons for keeping the existing format.
4). In Section 2.2.4:
E. For historical reasons, the UN numeric code 830 (Channel
Islands), which was not registered at the time this document
was adopted and had, at that time, no corresponding ISO
3166-1 code, MAY be entered into the IANA registry via the
Why is this a MAY? I.e., should this be registered or not?
process described in Section 3.5, provided no ISO 3166-1 code
with that exact meaning has been previously registered.
5). The citation of RFC 2860 in the first paragraph of Section 2.2 is improper. 2860 does not define IANA (which is considered a well-known abbreviation by the RFC Editor) or any of its properties that are relevant to this specific set of registries. So this reference is both improper and unnecessary.
6). In Section 2.2.3:
2. Script subtags consist of four letters and were defined according
to [ISO15924]--"Codes for the representation of the names of
scripts": alpha-4 script codes, or subsequently assigned by the
ISO 15924 registration authority or governing standardization
bodies, denoting the script or writing system used in conjunction
with this language. Only codes assigned by ISO 15924 will be
considered for registration.
The first sentence is hard to understand. It looks like it has misplaced punctuation.
7). In Section 3.7:
Failure to maintain this record, maintain the corresponding registry, or meet other conditions imposed by this section of this document MAY be appealed to the IESG [RFC2028] under the same rules as other IETF decisions (see [RFC2026]) and MAY result in the authority to maintain the extension being withdrawn or reassigned by the IESG.
It is not clear to whom this procedure applies. If it meant to apply to IANA, then it seems to contradict IETF agreement with IANA as specified in RFC 2860.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.