Subject: Re: [Ltru] Additional issues with 4646bis raised by an Apps Review Team review

From: "Doug Ewell" <[email-masked]>
Date: Sun, 24 May 2009 09:47:14 -0600

Alexey Melnikov <alexey dot melnikov at isode dot com> quoted the Apps 
Review Team:

> 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.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ