A-label definition

John C Klensin klensin at jck.com
Tue Jun 24 18:16:08 CEST 2008



--On Tuesday, 24 June, 2008 00:51 +0200 Frank Ellermann
<hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com> wrote:

>> one could still have an FQDN of 1.2.3.4.5 or 1.2.3, as 
>> long as 1.2.3.4 is avoided.
> 
> Some stupid software looks for "only dots or digits" for
> its decision "might be a FQDN or IPv4", and it doesn't
> count dots, or check that 1.2.3.456 is no IPv4.  Now you
> could say "this software is broken, fix it", but it was
> good enough to handle IPv4 vs. FQDN implicitly.  
> 
>> not because there would be serious problems for very 
>> careful applications.
> 
> Sure, some protocols insist on square brackets for IPs,
> after that decision the whole issue doesn't exist.  But
> other popular protocols don't for IPv4, notably STD 66.

Frank,

There are two schools of protocol design here.  One starts from
the assumption that heuristics are a bad idea, partially because
different folks use different ones.  The other likes them.  The
first view gets one "address literals must be an square
brackets", the second gets the discussion you and Mark are
having and an argument about whether 1.2.3.456 ought to be
looked up as a domain name.  

I can't usefully participate in that discussion because every
example of something that might be considered as an address (or
domain name) leads me to believe even more strongly that any
protocol that does not make a clear lexical distinction between
address literals and domain names is defective, if not broken.

The bad news is that we have lots of protocols that don't --
SMTP is definitely in the minority in requiring a lexical
distinction.  URNs (BCP66/RFC3406) is certainly not the only
one; the problem goes back to most UIs to Telnet and FTP if not
earlier.

     john



More information about the Idna-update mailing list