1). In Section 3.5: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.
The list is *already* hosted at alvestrand.no and listed, like many others, at https://datatracker.ietf.org/list/nonwg/ as an IETF Non-WG Mailing List. This passage merely confirms what is already the case, for the benefit of those who might be confused by this arrangement or who might feel it compromises the legitimacy of the list.
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.
IANA informed the WG that it was switching its registries to XML *internally* for maintenance purposes, and that its intent was not to require the revision of all existing protocols that did not already use XML. There are already tools and processes that use the Language Subtag Registry in its existing format. The WG argued at great length about this and decided not to make this breaking change.
4). In Section 2.2.4: Why is this a MAY? I.e., should this be registered or not?
It may be registered if someone requests it through the normal, uh, channels. (As a technical contributor, I think doing so would be a mistake.) It is almost certainly not an RFC 2119 MAY, but just a statement that something is possible.
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.
Someone probably suggested this reference as a way of expanding the abbreviation. It's been there since RFC 3066.
7). In Section 3.7: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.
It applies to the maintaining authority defined in the RFC that establishes the extension. This is described unambiguously, though perhaps not with maximum clarity, in Section 3.7.
-- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.htmlhttp://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.