<font face="georgia,serif">Looks reasonable to me.</font><div><font face="georgia,serif"><br clear="all"></font><font face="georgia, serif">Mark<br><br><i>— Il meglio è l’inimico del bene —</i></font><br>
<br><br><div class="gmail_quote">On Thu, Oct 21, 2010 at 10:12, =JeffH <span dir="ltr"><<a href="mailto:Jeff.Hodges@kingsmountain.com">Jeff.Hodges@kingsmountain.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
In the httpstate, we've almost completed our spec on HTTP Cookies (as they actually are implemented & deployed). In the process, we've attempted to properly reference the IDNA specs, but of course with the recent publication of IDNA2008 and its obsoleting IDNA2003, this presented a bit of head-scratching WRT how to properly reference them since IDNA2008 is not backwards compatible and there's going to be a transition period for some time.<br>

<br>
Below's what we came up with (the following are relevant excerpts from <<a href="http://tools.ietf.org/html/draft-ietf-httpstate-cookie" target="_blank">http://tools.ietf.org/html/draft-ietf-httpstate-cookie</a>>).<br>

<br>
How does that look to you folks?<br>
<br>
thanks,<br>
<br>
=JeffH<br>
[ httpstate chair & document shepherd ]<br>
<br>
<br>
...<br>
<br>
5.1.2.  Canonicalized host names<br>
<br>
   A canonicalized host name is the string generated by the following<br>
   algorithm:<br>
<br>
   1.  Convert the host name to a sequence of NR-LDH labels (see Section<br>
       2.3.2.2 of [RFC5890]) and/or A-labels according to the<br>
       appropriate IDNA specification [RFC5891] or [RFC3490] (see<br>
       Section 6.3 of this specification)<br>
<br>
   2.  Convert the labels to lower case.<br>
<br>
   3.  Concatenate the labels, separating each label from the next with<br>
       a %x2E (".") character.<br>
<br>
...<br>
<br>
<br>
6.3.  IDNA dependency and migration<br>
<br>
   IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not<br>
   backwards-compatible.  For this reason, there will be a transition<br>
   period (possibly of a number of years).  User agents SHOULD implement<br>
   IDNA2008 [RFC5890] and MAY implement [Unicode Technical Standard #46<br>
   <<a href="http://unicode.org/reports/tr46/" target="_blank">http://unicode.org/reports/tr46/</a>>] in order to facilitate a smoother<br>
   IDNA transition.  If a user agent does not implement IDNA2008, the<br>
   user agent MUST implement IDNA2003 [RFC3490].<br>
<br>
<br>
...<br>
<br>
10.  References<br>
<br>
10.1.  Normative References<br>
<br>
...<br>
<br>
   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,<br>
              "Internationalizing Domain Names in Applications (IDNA)",<br>
              RFC 3490, March 2003.<br>
<br>
              See Section 6.3 for an explanation why the normative<br>
              reference to an obsoleted specification is needed.<br>
<br>
<br>
   [RFC5890]  Klensin, J., "Internationalized Domain Names for<br>
              Applications (IDNA): Definitions and Document Framework",<br>
              RFC 5890, August 2010.<br>
<br>
   [RFC5891]  Klensin, J., "Internationalized Domain Names in<br>
              Applications (IDNA): Protocol", RFC 5891, August 2010.<br>
<br>
<br>
...<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no" target="_blank">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</blockquote></div><br></div>