I agree. On Mon, Mar 3, 2008 at 8:34 AM, <Karen_Broome <at> spe.sony.com> wrote: > > I think the ABNF in the draft should unambiguously indicate that the source > for region data is ISO 3166-1. We have had requestors try to use ISO 3166-2 > to indicate subregions of a country in the past (Valencia comes to mind). > Today it just says "ISO 3166" without specifying which part. > > Regards, > > Karen Broome > Metadata Systems Designer > Sony Pictures Entertainment > 310.244.4384 > _______________________________________________ > Ltru mailing list > Ltru <at> ietf.org > https://www.ietf.org/mailman/listinfo/ltru > > -- -- Mark
Done. Addison Mark Davis wrote: > I agree. > > On Mon, Mar 3, 2008 at 8:34 AM, <Karen_Broome <at> spe.sony.com> wrote: >> I think the ABNF in the draft should unambiguously indicate that the source >> for region data is ISO 3166-1. We have had requestors try to use ISO 3166-2 >> to indicate subregions of a country in the past (Valencia comes to mind). >> Today it just says "ISO 3166" without specifying which part. >> >> Regards, >> >> Karen Broome >> Metadata Systems Designer >> Sony Pictures Entertainment >> 310.244.4384 >> _______________________________________________ >> Ltru mailing list >> Ltru <at> ietf.org >> https://www.ietf.org/mailman/listinfo/ltru >> >> > > > -- -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature.
(For the records and the archives.) Someone wrote in http://article.gmane.org/gmane.ietf.idn/1676 that some part of RFC 4646 has been "defeated at ISO TC46". Is this true?
Hi - > From: "Nicolas Krebs" <nicolas1.krebs3 <at> netcourrier.com> > To: <ltru <at> ietf.org> > Sent: Saturday, March 08, 2008 10:30 AM > Subject: [Ltru] RFC 4646 and ISO TC46 > > (For the records and the archives.) > > Someone wrote in http://article.gmane.org/gmane.ietf.idn/1676 > that some part of RFC 4646 has been "defeated at ISO TC46". > Is this true? The statement makes no sense. RFC 4646 is an IETF BCP, not an ISO document. Due to his persistent disruptive misbehavior, and pursuant to RFC 3683, the posting privileges of author of that article were revoked in this WG about two years ago. I strongly suggest not bringing his disinformation onto this list, even by reference. Randy ltru co-chair
I just now submitted draft-12 using the tool. Alas, since the tool doesn't pick up the author's data from our documents correctly, we are in the manual submission process. There is also the current moratorium due to IETF-71. Look for the updated draft to be officially posted after that. Please note that I have also updated inter-locale with the submitted version: http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-12.txt http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-12.html http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-12.xml WDiff: http://tinyurl.com/2nybuo Note: inter-locale.com may be down intermittently over the next few days. I'm having the DSL line upgraded. Addison -- -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature.
As far as I can tell, all of the following comments are editorial,
except perhaps the comment that an expected technical change was not
made. If anyone spots a technical comment, please accept my apologies
and move it to a separate Subject line. None of these should be
showstoppers; a few date back before the present draft, for which I
apologize.
Section 2, introduction:
The space after the comma in the passage "primary for human
communication,such as" has been deleted. Please add it back.
Section 2.1, 2nd paragraph:
The last sentence mentions "the subtag registry" before it has actually
been defined or described anywhere. I suggest adding a reference to
Section 3, or at the very least making the reference a bit more formal:
"Thus, a parser need not have an up-to-date copy (or any copy at all) of
the IANA Language Subtag Registry to perform most searching and matching
operations."
Section 2.2.4:
This section should have all remaining references to "ISO 3166" changed
to "ISO 3166-1", in keeping with the recent change made in the ABNF.
For example, the passages in Section 2.2.4, item 3 about "ISO 3166
alpha-2 codes" could be misinterpreted or deliberately twisted to refer
to ISO 3166-2 alpha-2 code elements such as "OR". I would actually
recommend searching the entire document for "ISO 3166" and changing each
instance to "ISO 3166-1" unless the result would be simply wrong.
Section 3.1.6, 2nd paragraph from the end:
This section continues to state: "The field 'Preferred-Value' MUST NOT
be modified once created in the registry." While AFAIK there was no
declared consensus to change this, I was quite sure there was popular
support for making this field mutable, so that users of the Registry
would not have to follow a sequence of P-V's, say from "i-hak" to
"zh-hakka" to "hak". I had been delaying the release of
draft-4645bis-05 in anticipation of this change, but seeing none, I will
go ahead and release the draft with the same P-V's as before. (Q: Why a
new draft-4645bis? A: Because the ISO 639-3 code lists have changed.)
Section 4.2, 3rd paragraph, just before bullet points:
Change spelling of "very" to "vary".
Section 8, 29th bullet point (6th from the end):
The reference to RFC 4324 looks erroneous, and probably should be RFC
5234.
Section 9 generally:
I was surprised to see RFC 4645, which pertained to RFC 4646, listed as
a normative reference while draft-4645bis, which pertains to the present
draft, is only listed as informative. I think this is because Section
2.2.4, item 3 (E) makes reference to RFC 4645, and that item has not
been changed since it appeared in RFC 4646.
Regarding the list in question, only 830 "Channel Islands" remains, and
IMHO the 3166/MA would be crazy to assign this code now that GG and JE
have been individually assigned. However, it is possible, and this
situation does justify a reference to RFC 4645. But I still need a
normative/informative lawyer to explain to me why that reference is
normative while the reference to draft-4645bis is not.
Section 9.1, 17th item (2nd from the end):
Change spelling of "Freitag" to "Freytag". If Asmus were on the list, I
would leave it up to him to correct the spelling or form of his name,
but I don't think he is.
Section 9.2, 9th item (5th from the end):
Change month "12" to "December". Perhaps surprisingly, the rfc2xml tool
doesn't automatically substitute month names when a numeric month and no
day are given. Perhaps one day...
--
Doug Ewell * Fullerton, California, 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 ˆ
_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Editor hat on; responses follow. > > > Section 2, introduction: > > The space after the comma in the passage "primary for human > communication,such as" has been deleted. Please add it back. Done. > > > Section 2.1, 2nd paragraph: > > The last sentence mentions "the subtag registry" before it has actually > been defined or described anywhere. I suggest adding a reference to > Section 3, or at the very least making the reference a bit more formal: > > "Thus, a parser need not have an up-to-date copy (or any copy at all) of > the IANA Language Subtag Registry to perform most searching and matching > operations." Done, although I edited the sentence somewhat in order to address this issue. It now reads: -- Thus, a parser need not have a list of valid tags or subtags (such as a copy of some version of the IANA Language Subtag Registry) in order to perform common searching and matching operations. -- I admit to some pain removing the pithy "or any copy at all". > > > Section 2.2.4: > > This section should have all remaining references to "ISO 3166" changed > to "ISO 3166-1", in keeping with the recent change made in the ABNF. > For example, the passages in Section 2.2.4, item 3 about "ISO 3166 > alpha-2 codes" could be misinterpreted or deliberately twisted to refer > to ISO 3166-2 alpha-2 code elements such as "OR". I would actually > recommend searching the entire document for "ISO 3166" and changing each > instance to "ISO 3166-1" unless the result would be simply wrong. Done. I did a search-and-replace. Note that a few instances of naked "ISO 3166" remain. These are all references to ISO 3166 as a standards body or in general. When in doubt, I made it ISO 3166-1. > > > Section 3.1.6, 2nd paragraph from the end: > > This section continues to state: "The field 'Preferred-Value' MUST NOT > be modified once created in the registry." While AFAIK there was no > declared consensus to change this, I was quite sure there was popular > support for making this field mutable, so that users of the Registry > would not have to follow a sequence of P-V's, say from "i-hak" to > "zh-hakka" to "hak". I had been delaying the release of > draft-4645bis-05 in anticipation of this change, but seeing none, I will > go ahead and release the draft with the same P-V's as before. (Q: Why a > new draft-4645bis? A: Because the ISO 639-3 code lists have changed.) (editor hat off) I think a declaration from the chairs on this item is in order. I thought it was at or near consensus myself. (retrieves editor's hat) > > > Section 4.2, 3rd paragraph, just before bullet points: > > Change spelling of "very" to "vary". Done. > > > Section 8, 29th bullet point (6th from the end): > > The reference to RFC 4324 looks erroneous, and probably should be RFC > 5234. It's a typo. Fixed. Also: replaced with an <xref> so that it'll stay fixed. > > > Section 9 generally: > > I was surprised to see RFC 4645, which pertained to RFC 4646, listed as > a normative reference while draft-4645bis, which pertains to the present > draft, is only listed as informative. I think this is because Section > 2.2.4, item 3 (E) makes reference to RFC 4645, and that item has not > been changed since it appeared in RFC 4646. Actually, this is deliberate and probably NOT an error. RFC 4645 did, in fact, define the list in question. There is a reference to the document in normative language in Section 2.2.4, item 3, subitem E. All references to 4645bis (aka "registry-update") are informative in that the document plays no role in any of the normative language of 4646bis. I suppose a case could be made that instructions to IANA on where to get the updated registry would be normative, though. Incidentally, RFC 4645 was an *informative* reference to RFC 4646. It was promoted because normative language was added in this version requiring a look at the list in 4645 in that one very special case. > > > Section 9.1, 17th item (2nd from the end): > > Change spelling of "Freitag" to "Freytag". If Asmus were on the list, I > would leave it up to him to correct the spelling or form of his name, > but I don't think he is. Done. > > > Section 9.2, 9th item (5th from the end): > > Change month "12" to "December". Perhaps surprisingly, the rfc2xml tool > doesn't automatically substitute month names when a numeric month and no > day are given. Perhaps one day... Done. -- -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature.
As far as I can tell, all of the following comments are editorial,
except perhaps the comment that an expected technical change was not
made. If anyone spots a technical comment, please accept my apologies
and move it to a separate Subject line. None of these should be
showstoppers; a few date back before the present draft, for which I
apologize.
Section 2, introduction:
The space after the comma in the passage "primary for human
communication,such as" has been deleted. Please add it back.
Section 2.1, 2nd paragraph:
The last sentence mentions "the subtag registry" before it has actually
been defined or described anywhere. I suggest adding a reference to
Section 3, or at the very least making the reference a bit more formal:
"Thus, a parser need not have an up-to-date copy (or any copy at all) of
the IANA Language Subtag Registry to perform most searching and matching
operations."
Section 2.2.4:
This section should have all remaining references to "ISO 3166" changed
to "ISO 3166-1", in keeping with the recent change made in the ABNF.
For example, the passages in Section 2.2.4, item 3 about "ISO 3166
alpha-2 codes" could be misinterpreted or deliberately twisted to refer
to ISO 3166-2 alpha-2 code elements such as "OR". I would actually
recommend searching the entire document for "ISO 3166" and changing each
instance to "ISO 3166-1" unless the result would be simply wrong.
Section 3.1.6, 2nd paragraph from the end:
This section continues to state: "The field 'Preferred-Value' MUST NOT
be modified once created in the registry." While AFAIK there was no
declared consensus to change this, I was quite sure there was popular
support for making this field mutable, so that users of the Registry
would not have to follow a sequence of P-V's, say from "i-hak" to
"zh-hakka" to "hak". I had been delaying the release of
draft-4645bis-05 in anticipation of this change, but seeing none, I will
go ahead and release the draft with the same P-V's as before. (Q: Why a
new draft-4645bis? A: Because the ISO 639-3 code lists have changed.)
Section 4.2, 3rd paragraph, just before bullet points:
Change spelling of "very" to "vary".
Section 8, 29th bullet point (6th from the end):
The reference to RFC 4324 looks erroneous, and probably should be RFC
5234.
Section 9 generally:
I was surprised to see RFC 4645, which pertained to RFC 4646, listed as
a normative reference while draft-4645bis, which pertains to the present
draft, is only listed as informative. I think this is because Section
2.2.4, item 3 (E) makes reference to RFC 4645, and that item has not
been changed since it appeared in RFC 4646.
Regarding the list in question, only 830 "Channel Islands" remains, and
IMHO the 3166/MA would be crazy to assign this code now that GG and JE
have been individually assigned. However, it is possible, and this
situation does justify a reference to RFC 4645. But I still need a
normative/informative lawyer to explain to me why that reference is
normative while the reference to draft-4645bis is not.
Section 9.1, 17th item (2nd from the end):
Change spelling of "Freitag" to "Freytag". If Asmus were on the list, I
would leave it up to him to correct the spelling or form of his name,
but I don't think he is.
Section 9.2, 9th item (5th from the end):
Change month "12" to "December". Perhaps surprisingly, the rfc2xml tool
doesn't automatically substitute month names when a numeric month and no
day are given. Perhaps one day...
--
Doug Ewell * Fullerton, California, 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 ˆ
_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Addison Phillips <addison at yahoo dash inc dot com> wrote: >> "Thus, a parser need not have an up-to-date copy (or any copy at all) >> of the IANA Language Subtag Registry to perform most searching and >> matching operations." > > Done, although I edited the sentence somewhat in order to address this > issue. It now reads: > > -- > Thus, a parser need not have a list of valid tags or subtags (such as > a copy of some version of the IANA Language Subtag Registry) in order > to perform common searching and matching operations. > -- > > I admit to some pain removing the pithy "or any copy at all". Actually I prefer my version, which is not only higher in pith but also avoids giving the impression that any old list of valid tags or subtags is an acceptable substitute for the LSR. An alternative way to address the forward-reference issue would be "... the IANA Language Subtag Registry (described in Section 3) to perform..." But this is not critical. > Done. I did a search-and-replace. Note that a few instances of naked > "ISO 3166" remain. These are all references to ISO 3166 as a standards > body or in general. When in doubt, I made it ISO 3166-1. Perfect. > (editor hat off) I think a declaration from the chairs on this item is > in order. I thought it was at or near consensus myself. Should I wait on draft-4645bis-05 then, or go ahead with it? >> I was surprised to see RFC 4645, which pertained to RFC 4646, listed >> as a normative reference while draft-4645bis, which pertains to the >> present draft, is only listed as informative... > > Actually, this is deliberate and probably NOT an error. RFC 4645 did, > in fact, define the list in question. There is a reference to the > document in normative language in Section 2.2.4, item 3, subitem E. OK. -- Doug Ewell * Fullerton, California, 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 ˆ _______________________________________________ Ltru mailing list Ltru <at> ietf.org https://www.ietf.org/mailman/listinfo/ltru
RSS Feed4 | |
|---|---|
17 | |
145 | |
14 | |
1 | |
2 | |
1 | |
2 | |
1 | |
7 | |
1 | |
2 | |
5 | |
14 | |
10 | |
7 | |
13 | |
34 | |
88 | |
346 | |
208 | |
186 | |
54 | |
287 | |
25 | |
116 | |
122 | |
181 | |
44 | |
30 | |
341 | |
500 | |
910 | |
67 | |
42 | |
277 | |
122 | |
324 | |
173 | |
176 | |
117 | |
125 | |
181 | |
201 | |
153 | |
335 | |
374 | |
137 | |
116 | |
220 | |
242 | |
395 | |
667 | |
145 | |
89 | |
134 | |
64 | |
63 | |
158 | |
289 | |
46 | |
108 | |
218 | |
145 | |
316 | |
427 | |
597 | |
545 | |
513 | |
996 | |
430 |
