IDNA Errors on "https://r2---sn-huoa-cvhl.googlevideo.com/crossdomain.xml" URL

[Billy2011]

This URL works in Firefox but not in my App!

[kjd]

At first glance, this is not actually wrong. IDNA-compliant host names can not have hyphens in the third and fourth positions unless they are legal IDNA labels according to RFC 5890:

   To facilitate clear description, two new subsets of LDH labels are
   created by the introduction of IDNA.  These are called Reserved LDH
   labels (R-LDH labels) and Non-Reserved LDH labels (NR-LDH labels).
   Reserved LDH labels, known as "tagged domain names" in some other
   contexts, have the property that they contain "--" in the third and
   fourth characters but which otherwise conform to LDH label rules.
   Only a subset of the R-LDH labels can be used in IDNA-aware
   applications.  That subset consists of the class of labels that begin
   with the prefix "xn--" (case independent), but otherwise conform to
   the rules for LDH labels.  That subset is called "XN-labels" in this
   set of documents.  XN-labels are further divided into those whose
   remaining characters (after the "xn--") are valid output of the
   Punycode algorithm [RFC3492] and those that are not (see below).  The
   XN-labels that are valid Punycode output are known as "A-labels" if
   they also meet the other criteria for IDNA-validity described below.
   Because LDH labels (and, indeed, any DNS label) must not be more than
   63 octets in length, the portion of an XN-label derived from the
   Punycode algorithm is limited to no more than 59 ASCII characters.
   Non-Reserved LDH labels are the set of valid LDH labels that do not
   have "--" in the third and fourth positions.

The question is should the idna library change? It currently throws an exception when it gets an illegal value, but arguably this string should never have attempted IDNA conversion, and should not really be a hostname in a modern environment.