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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf