Web Key Directory handling of IDN

[Matthias Wimmer]

Hi,


El 2016-11-07 20:17:19, Werner Koch escribió:
> Well, if a user decides to use non-ASCII adresses they need to live with
> the strict but impractical rules of RFC5322 which says that case folding
> may or may not happen.

In think that in the case the following rule from RFC6530, section 10.1
applies:

   For the particular case of mailbox names that contain non-ASCII
   characters in the local part, domain part, or both, special attention
   MUST be paid to Unicode normalization [Unicode-UAX15], in part
   because Unicode strings may be normalized by other processes
   independent of what a mail protocol specifies (this is exactly
   analogous to what may happen with quoting and dequoting in
   traditional addresses).  Consequently, the following principles are
   offered as advice to those who are selecting names for mailboxes:

   o  In general, it is wise to support addresses in Normalized form,
      using at least Normalization Form NFC.  Except in circumstances in
      which NFKC would map characters together that the parties
      responsible for the destination mail server would prefer to be
      kept distinguishable, supporting the NFKC-conformant form would
      yield even more predictable behavior for the typical user.

   o  It will usually be wise to support other forms of the same local-
      part string, either as aliases or by normalization of strings
      reaching the delivery server: the sender should not be depended
      upon to send the strings in normalized form.

   o  Stated differently and in more specific terms, the rules of the
      protocol for local-part strings essentially provide that:

      *  Unnormalized strings are valid, but sufficiently bad practice
         that they may not work reliably on a global basis.  Servers
         should not depend on clients to send normalized forms but
         should be aware that procedures on client machines outside the
         control of the MUA may cause normalized strings to be sent
         regardless of user intent.

      *  C0 (and presumably C1) controls (see The Unicode Standard
         [Unicode]) are prohibited, the first in RFC 5321 and the second
         by an obvious extension from it [RFC5198].

      *  Other kinds of punctuation, spaces, etc., are risky practice.
         Perhaps they will work, and SMTP receiver code is required to
         handle them without severe errors (even if such strings are not
         accepted in addresses to be delivered on that server), but
         creating dependencies on them in mailbox names that are chosen
         is usually a bad practice and may lead to interoperability
         problems.


Regards,
Matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: </pipermail/attachments/20161108/2c37712f/attachment.sig>