| John Clews |
Fix document dates |
Closed. Fixed in draft-02. |
| John Clews |
Use LOCODEs |
Rejected |
| Jeremy Carroll |
how about 'und-latn':
|
?? |
| Peter Constable |
Use case for extensions.
|
No action. |
| Mike Ksar |
Reference an alias file in IANA considerations.
|
Rejected |
| Mike Ksar |
Add back ISO 3166 alpha3.
|
Rejected |
| Doug Ewell |
Make use of UN M49 codes very clear.
|
Closed. Fixed in draft-02 |
| Doug Ewell |
Resolve when ISO3166 reassigns take effect.
|
Closed. Fixed in draft-02. |
| Doug Ewell |
Variant subtag normative use.
|
Rejected |
| Jeremy Carroll |
Mutual intelligibility.
|
Rejected |
| Harald |
Facetious: registry of registry
|
Rejected |
| Ted Hardie | List relegated RFCs in intro and abstract. Forward pointer in intro to changelist. | Draft-03. |
| Ted Hardie | Why do you need to reserve "s" separately from the others, since
"s" and all others will be used after later standards action? Later
sections of the document seem to semi-specify "s", rather than
either giving a full specification or just reserving it. I'm concerned about
that, and I would like to see more text in the document describing
why this is the right choice. Note also that an update of this document
might also introduce single-character subtags (that is, a full-on revision
would not be needed to introduce an update describing the use of "s"
or some other single-character subtag).
| Draft-03. Removed -s from extlang. Described syntax for extensions. Described revision mechanism. |
| Ted Hardie | wording: "revision or update to this document" related to reservation of -s- | Draft-03. Changed. |
| Ted Hardie | The language above implies no new i-variants are permitted; please
clarify the language in this regard and ensure that the document is
consistent. | Draft-03. Forbid use of i-. |
| Ted Hardie | Section 2.3: While no one would disagree with the sentiment, this text could
easily be misinterpreted as "the world would be better if everyone
used the same language". Please clarify the text. | Draft-03. Changed. |
| Ted Hardie | Also, the intended
status of this document is BCP; attempting to introduce a MUST-level
requirement for all subsequent application protocols is not really
appropriate. Describing why it is best current practice makes more
sense than attempting to impose a specific style of specification
(variance from this text) on later authors.
| Rejected. |
| Ted Hardie | I'm also concerned that this text:
When a language has both an ISO 639-1 2-character code and an ISO
639-2 3-character code, you MUST use the ISO 639-1 2-character
code.
If an application choose to use only 3-character codes, for example,
but otherwise follows this set of best practices, what is the concern?
In other words, why is this a MUST and not a SHOULD? Or did you
mean for the application-specific rules noted above to override this?
| Rejected. Current practice. |
| Ted Hardie | In the IANA considerations section:
When the two week period has passed, the subtag reviewer, who is
appointed by the IETF Applications Area Director, either forwards the
request to IANA@IANA.ORG, or rejects it because of significant
objections raised on the list. Note that the reviewer can raise
objections on the list himself, if he or she so desires. The
important thing is that the objection must be made publicly.
There are currently multiple area directors for APPs, and the general
feeling now is that such appointments should be made by the IESG, rather
than individual areas, to allow for shifting responsibilities.
| Draft-03. Accepted and changed. |
| Peter Constable |
Make normative subtag usage explicit in the registration.
|
Rejected.
|
| Peter Constable |
Clarify: "...content as "Martian", can I
use "qaa", or would it have to be "x-qaa", or can I use "x-martian"?
(I'd suggest alternate wording, but I'm really not sure what is
intended.) Same for the comparable paragraph in relation to ISO 15924." | Draft-04.Accepted. |
| Peter Constable | Next paragraph change "IANA registered primary..." to "IANA-registered
primary..."
| Draft-04. Accepted. |
| Peter Constable | Make region subtag meaning clearer. | Draft-04. Partially accepted. |
| Addison Phillips | Allow mixed language range syntax (e.g. de-* or *-CH) | Can of worms. Reject. Higher level protocol. |
| Peter Constable | This would mean removing the length NOTE after point 6 (which, while
> carried forward from RFC 3066, I realize, is problematic IMO in that it
> is presented as a quotation yet has no source reference). | Reject. Extant text. No reason to change it. |
| Peter Constable | Item 4 after par 3: Removed "provoking" comment. (Suggested text supplied.) | Reject. Verbatim. |
| Peter Constable | Section 2.4, par 4: There appears to be ambiguous usage of "tag" between
the meanings 'a symbolic identifier as defined in this specification'
and 'a declaration of linguistic properties of information objects'. | Draft-04. Accepted. |
| Peter Constable | Section 2.4.1, par 1: Wording could be tightened up (is a language range
a set or a symbol?). | Draft-04. Accepted. |
| Peter Constable | 2.4.3: Is this saying that extensions should be put into alphabetical
order when *generating* tags, or when *comparing* tags? | Draft-04. Accepted. |
| Peter Constable | Also, in par 3, it says "... is correctly ordered...": is "correctly"
the appropriate word here, or is "canonically" better? The bottom line
is *can* I tag data or send a request using (e.g.)
"en-B-ext3-ext2-A-ext1"? Does the RFC permit me to do so or not? | Draft-04. Accepted. |
| Peter Constable | 3.1: Re the registration form: Is there some IETF policy that restricts
us to ask only for the native name of a language *transcribed into
ASCII*? | Rejected. This is an IETF thing. |
| Peter Constable | 3.2, par 4: Will tags like "zh-Hant" and "en-boont" be marked as
*obsoleted* or *superceded*? Here you say "obsoleted"; back in section
2.2.1 you said "superceded". | Draft-04. Accepted. |
| Peter Constable | Question about suitability of extensions mechanism. | rejected. |
| Mark Davis | Modify private_use ABNF to be consistent (once in private use, always in PU) | Draft-04. Accepted. |
| Addison Phillips | S 2.4: ignore case when ordering | Draft-04. Accepted. |
| MD/AP | Validation. Use the XML terminology? well-formed or valid. A well-formed tag is one that meets all of the constraints (except that subtags need not be checked for registration or current standardization) | Well-formed
Must check:
BNF
Grandfathered list
Explanations
Except doesn't have to check
- against the ISO codes: language, script, region
- against registered-lang
Valid
Must check:
- check ISO codes
- registered-lang (as at some date) |