Douglas Otis wrote: > > On 5/17/10 10:06 AM, Joe Touch wrote: > > My point here is that if you're discussing alternatives, you need to > > address why this alternative was not used. There may be useful reasons > > (in specific, using a separate command allows you to reuse some error > > codes more usefully), but you're also incurring an extra round trip, > > which people tend to count these days. > > > Joe, > > The use of AUTH follows HOST and precedes USER and PASS. Your > suggestion of combining USER+HOST exposes USER. > > International consensus was reached between the ISO, IETF, ITU, and > UNCEFACT on use of UTF-8 for interoperability. However, this draft > requires Puny-code input for international domain names. While > Puny-code allows IDNs to be encoded using ASCII, Puny-code is not > intended as a human interface, nor is Puny-code interoperable with > existing name services, and certificate validations. Distinguished > names in certs are UTF-8 encoded. Local name services such as LLMNR, > mDNS or Bonjour resolve domain names using UTF-8 queries.
There may be a misunderstanding. When performing server endpoint identification (similar to what is suggested for HTTP over TLS in rfc-2818), then the prefered method is to match against dNSName subjectAltNames, which are IA5String. Hostnames in the CN= part of certificates are also pure IA5Strings, because hostnames were pure IA5Strings when this scheme was originally devised and it has been deprecated many years ago. -Martin _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
