attachment-0001
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Ira,<div><br></div><div>There appears to be a serious issue with how the IETF is tracking 1766. The following link points to 3066 AND 3282:</div><div><br></div><div> <a href="http://tools.ietf.org/html/rfc1766">http://tools.ietf.org/html/rfc1766</a></div><div><br></div><div>3282 has not been updated.</div><div><br></div><div>3066 points to 4646 and 4647, and 4646 points to 5646.</div><div><br></div><div>So the currently-in-effect RFCs (replacing 1766) are:</div><div><br></div><div> RFC 3282: Content Language Headers</div><div> RFC 4647: Matching of Language Tags</div><div> RFC 5646: Tags for Identifying Languages</div><div><br></div><div>I am not going to rant about what the ISO and IETF have done to language tags. However, I do think it would be useful to add some text to IPP Everywhere to talk about the current state of affairs and some general guidelines, namely:</div><div><br></div><div>1. Use the rules in RFC 4647 for matching language tags.</div><div><br></div><div>2. Validate language tag values by supported characters - lowercase letters, digits, and "-".</div><div><br></div><div>3. Do not support extended ISO 639 language codes since technically they violate RFC 5656 (which requires the shortest ISO 639 code be used); for example, "english" is not OK but "en", "en-us", "en-uk", etc. are fine.</div><div><br></div><div>4. Expect Clients to make requests with language codes that do not match the generated-natural-language-supported values but map to them using the matching rules in #1.</div><div><br></div><div>For #4 the common issues I've dealt with in CUPS are:</div><div><br></div><div>- "no" (formerly "Norwegian Bokmål) is now "nb" for clarity; the other (less) common language in Norway is "Norwegian Nynorsk" ("nn").</div><div>- "zh-cn" is now "zh-hans", "zh-hans-cn", or "zh-hant-cn" (based on usage on Linux/UNIX)</div><div>- "zh-tw" is now "zh-hant", "zh-hans-tw", or "zh-hant-tw" (based on usage on Linux/UNIX)</div><div><br></div><div>The latter issue is the one that causes the greatest interoperability issues, and one that I have fielded many bugs for in CUPS. In some future release libcups will have a secret decoder ring API that does matching and substitution in the face of two different language codes that mean the same thing.</div><div><br></div><div>Thoughts?</div><div><br></div><div><br></div><div><br></div><div>On May 1, 2012, at 8:25 AM, Ira McDonald wrote:</div><div><div><br class="Apple-interchange-newline"><blockquote type="cite">Hi,<br><br>Per the IETF RFC Index, the latest successors to RFC 1766 are:<br><br>5646 Tags for Identifying Languages. A. Phillips, Ed., M. Davis, Ed..<br> September 2009. (Format: TXT=208592 bytes) (Obsoletes RFC4646) (Also<br>
BCP0047) (Status: BEST CURRENT PRACTICE)<br><br>4647 Matching of Language Tags. A. Phillips, M. Davis. September 2006.<br> (Format: TXT=45595 bytes) (Obsoletes RFC3066) (Also BCP0047) (Status:<br> BEST CURRENT PRACTICE)<br clear="all">
<br>Language tags can now include embedded tags for scripts, <br>geographic regions (not just countries), variants, and private <br>use tags.<br><br>Parsing language tags is no longer simple. Beware that they<br>embedded the script tag (if present) BEFORE the region tag<br>
(e.g., 'US'). Naive parsers will fail badly. See the ABNF on<br>pages 5-6 of RFC 5646. Reference libraries for parsing do<br>exist.<br><br>Both simple language tags (e.g., 'en') and simple region tags<br>
(e.g., 'US') can now be EITHER 2 or 3 characters. Script<br>tags must be exactly 4 characters. Variant tags can be 5-8<br>characters. See the examples right after the ABNF.<br><br>Of course the fixed language and country tags of 2 characters<br>
in the Printer MIB v2 are broken - they were broken when it<br>was published, but I failed to convince the other editors to let<br>me fix it (many naive clients would have been broken).<br><br>BEWARE: 3-character language tags are in common use<br>
and are in fact preferred where an older 2-character tag was<br>already registered (I can't explain why - never understood it).<br><br>Cheers,<br>- Ira<br><br><br>Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>
Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - TCG Embedded Systems Hardcopy SG<br>IETF Designated Expert - IPP & Printer MIB<br>
Blue Roof Music/High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>
mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<div style="display:inline">
</div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div><br>
<br><br><div class="gmail_quote">On Mon, Apr 30, 2012 at 8:04 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Glen,<div><div class="im"><br><div><div>On Apr 30, 2012, at 3:59 PM, Petrie, Glen wrote:</div><blockquote type="cite"><span style="border-collapse:separate;font-family:'Andale Mono';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div link="blue" vlink="purple" lang="EN-US">
<div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:Cambria"><font face="Cambria" size="3"><span style="font-size:12pt">Can someone provide me the reference for the natural-language registry is used by IPP?<u></u><u></u></span></font></div>
</div></div></span></blockquote></div><div><br></div></div>From RFC 2911:</div><div><br></div><div><span style="font-size:14px;font-family:'Helvetica Neue'"><pre style="font-size:1em;margin-top:0px;margin-bottom:0px"><span style="line-height:0pt;display:inline;white-space:pre-wrap;font-family:monospace;font-size:1em;font-weight:bold"><h4 style="line-height:0pt;display:inline;white-space:pre-wrap;font-family:monospace;font-size:1em;font-weight:bold">
<a name="13705b6f8f7eb75b_section-4.1.8">4.1.8</a> 'naturalLanguage'</h4></span>
The 'naturalLanguage' attribute syntax is a standard identifier for a
natural language and optionally a country. The values for this
syntax type are defined by <a href="http://tools.ietf.org/html/rfc1766" target="_blank">RFC 1766</a> [<a href="http://tools.ietf.org/html/rfc1766" title=""Tags for the Identification of Languages"" target="_blank">RFC1766</a>]. Though <a href="http://tools.ietf.org/html/rfc1766" target="_blank">RFC 1766</a>
requires that the values be case-insensitive US-ASCII [<a href="http://tools.ietf.org/html/rfc2911#ref-ASCII" target="_blank">ASCII</a>], IPP
requires all lower case to simplify comparing by IPP clients and
Printer objects. Examples include:
'en': for English
'en-us': for US English
'fr': for French
'de': for German
The maximum length of 'naturalLanguage' values used to represent IPP
attribute values is 63 octets.</pre></span><div><br></div><div>which leads to RFC 3282 (the replacement), which references ISO 639, 639-2, 3166, and 15924.</div><div><br></div><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:'Andale Mono';word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:'Andale Mono';word-spacing:0px"><div style="word-wrap:break-word">
_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div><div class="im"><br>--
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>, and is
<br>believed to be clean.
</div></div>
<br>_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
<br></blockquote></div><br>
</blockquote></div><br><div apple-content-edited="true">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div>
</div>
<br></div><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>