--On February 18, 2013 22:05:37 -0700 Peter Saint-Andre
<[email protected]> wrote:
Here I see something similar: in order to allow strings like
[email protected], an application protocol would need to define its
constucts along these lines:
Historically, Internet login identities have been freeform ASCII or UTF-8
strings. Widely deployed implementations have sometimes used other charsets
such as ISO-8859-1 even when it violates the standards. This shows need for
both UTF-8 support and validity enforcement in login identities.
Identity systems can impose additional structure as needed. A site's
identity system works best if it can span multiple protocols (e.g., IMAP,
POP, SMTP, XMPP, web form logins, etc). Architecturally, I think identity
systems are best viewed as independent of the consuming protocols even if a
lot of software is not implemented that way today. So I'd prefer to avoid
having application protocols imposing unnecessary constraints on identity
systems.
So we're balancing a need for validity enforcement for interoperability
(which is the intent behind NameClass) with a need for application
protocols to avoid breaking existing identity system models so it is
possible for this standard to deploy. This looks like a good engineering
problem to me. :-)
That said, we might want to allow some characters into the NameClass
that are outside LetterDigits ("A") in RFC 5892. I'm thinking
especially of some of the code points in Exceptions ("F"). This sounds
like an appropriate topic for discussion in Orlando...
Yes, I think that would be a good discussion to have. I would propose that
all the PVALID and CONTEXT characters from Exceptions (F) be added to
NameClass and state that implementations MAY enforce the CONTEXT
restrictions from RFC 5892.
- Chris
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
