LDH-label terminology

[Vint Cerf]

constraints on the scope and applicability of IDNs should be made  
visible early and clearly.

vint


On Jul 25, 2008, at 7:35 PM, John C Klensin wrote:

>
>
> --On Saturday, 26 July, 2008 01:21 +0200 Frank Ellermann
> <hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com> wrote:
>
>> John C Klensin wrote:
>>
>>> I sent a note off earlier today whose purpose is to dump much
>>> of this terminology stuff (and the 1123 clarification and
>>> related issues) onto the DNS experts and/or WG(s) or at least
>>> get them to work with us on it.  Don't know if that will be
>>> successful, but I'm  going to feel better for having tried.
>>
>> Good, if they don't answer -- busy to fix DNS worldwide -- we
>> can take this as carte blanche to define the minimum we need
>> for IDNAbis and to introduce "real" IDN TLDs as it pleases us.
>
> yes. But, for several reasons, I do expect some sort of answer.
> And it doesn't quite work that way -- under IETF rules, although
> not common courtesy, they could refuse to play at this stage and
> then tie things in knots because they didn't like out solution.
>
>> In another article you mentioned RFC 2673 for the difference
>> between "binary" and "octets".  IMHO we can ignore RFC 2673
>> for IDN.  The SPF folks also ignored it for RFC 4408 back in
>> 2005.  You could mention that in theory any octets goes (in
>> prose) somewhere.  That is relevant if folks try to use UTF-8
>> U-labels directly without first converting them to A-labels.
>
> I'd rather avoid as much of that as possible, probably for the
> same reason SPF did.  I was just trying to clarify Eric's
> taxonomy picture a bit so we were all sure we were talking about
> the same thing.
>
> Even the UTF-8 bit doesn't seem to me to be something we need to
> discuss.  There are many ways to violate any protocol, this
> among them.  I don't think we need to catalog the violations (or
> bypass attempts).  A UTF-8 string in the DNS presumably would
> not start with "xn--" and could not be a conforming A-label in
> any case, so we don't care (the protocols that _do_ enforce
> LDH-compliance would deal with such strings in their own way.
>
>> Of course using UTF-8 U-labels directly will fail, but if it
>> *happens* to be a valid octet label the corresponding domain
>> could be controlled by the bad guys => security consideration.
>>
>> Apart from that facet octet labels are irrelevant for IDNAbis;
>> and we can focus on "LDH" vs. "A" in some ways.  Without the
>> z-label business mentioned by Eric.  And without SRV-labels -
>> or is there something about IDNA and SRV I've never heard of ?
>
> The fact that one can't have the protocol part(s) of an SRV FQDN
> be IDNs will, I suspect, come back to generate complaints at
> some point.  I think "you can't do that" is worth saying
> explicitly just to head off the rather complicated an
> hard-to-diagnose errors that might result from someone trying to
> encode a string starting with an underscore and followed by some
> non-ASCII characters and expecting that to work (which it might,
> depending on how an application that retrieved SRV records was
> coded).
>
> Of course, the fact that "_" is DISALLOWED would be irrelevant
> if the application just saw the putative A-label and didn't make
> explicit checks on it, just decoded the thing to a Unicode
> string and only then looked for the leading underscore.  So I
> think it is worth mentioning, even if not worth spending much
> energy one.
>
>      john
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update