Dmitry and James,
I think several different issues are getting intertwined here,
some of which rise to the level of principles. It is clear that
we are making different assumptions about what is relevant and
important and almost as clear that we are not going to convince
each other. As I said earlier, that is why we pay the IESG the
big bucks.
In no particular order:
(1) I believe that, if you are trying to create an IETF
standards track protocol that draws on another IETF standards
track protocol for its motivation, you are obligated to follow
the specifications of that protocol and associated experience,
not just pick up its syntax. In the case of non-ASCII email
addresses, that includes making all-ASCII addresses available as
an alternative unless there is great confidence that they will
not be needed (e.g., for communications within a country using
that country's major script (and where relevant, language) and a
restricted set of email providers. Such a restriction might
actually be reasonable within a constrained business
transaction, especially when registrant, registry, registry, and
the domain itself primarily serve a particular country or
cluster of countries (see below).
The IETF and its predecessors have carefully avoided specifying
MUA, especially MUA-UI, behavior for well over 40 years. In
that context, the key difficulty with non-ASCII addresses may
not be easily discerned from our specifications. However, as
the EAI WG understood from the beginning, transporting non-ASCII
addresses across the Internet,in message header formats, even
delivery status notification (DSN) messages, is fairly easy. It
is especially easy by comparison to actually designing and
building software that interacts with users across a very broad
range of languages and writing systems. The usual solutions are
to either give up on that quality of MUA/UI-UX design and
instead design for a particular language community or small
cluster of them, but that leaves messages that use, or embed
addresses in, other languages and scripts in need of all-ASCII
(or some other common/agreed form) in greater or lesser trouble.
As a different, extreme, and nit-picky, example of where this
specification has failed to appreciate what the
Internationalized Email specifications say, thse specifications
for non-ASCII email addresses and headers make it quite clear
that there are no such things as an "EAI Address" or an "EAI
extension" and that the correct term is "SMTPUTF8". That would
not be important except that IETF specs should not be creating
confusion by using incorrect terminology (no matter how
prevalent elsewhere) and because it reinforces the concern that
the WG may not have paid careful attention to the relevant
specifications (beyond a citation of syntax) in creating this
one.
(2) As Patrik pointed out, there is a community interest (both
general and in ICANN policy) in making it easy for registrants
to switch registrars (whether the earlier registrar remains in
business or not). For a registrar to treat business
relationship data that do not affect users, various authorities,
or elements of the DNS itself, as confidential is entirely
reasonable. However, usable contact information for registrants
does not fall into that category but, instead, is information
registries have been required to have in their possession since
before there was an ICANN (a principle reaffirmed many times
since then).
(3) Whether a registrant is allowed to supply a non-ASCII email
address at all and, if they are allowed to do that, whether an
ASCII alternative should (or must) be supplied is, we are
agreed, a matter for registry-registrar agreements -- at least
until national governments, other authorities, or ICANN itself
step in. I don't think anyone has suggested that supplying an
alternative all-ASCII address through the protocol should be a
requirement imposed by the IETF (certainly I have not). I
imagine that the REGEXT WG making a strong recommendation on the
subject would even be viewed by some as an intrusion on ICANN's
scope of authority. However, it is important that the protocol
be able to accommodate the inclusion and transfer of that
alternate address information lest someone --perhaps even
someone acting on behalf of a registrar who believes its
interests would be served by making transfers difficult-- claim
in an ICANN forum that such information is unnecessary and
difficult to provide --and hence should be excluded from
discussions-- because the IETF decided it was not allowed in the
protocol.
(4) To say almost the same thing from a different perspective,
if the purpose of this specification is to reduce the number of
incompatible ways in which registry-registrar pairs do things,
then please recognize that there is a strong possibility (as
predicted by the SMTPUTF8 specification family), either
immediately or after experience starts to accumulate, that
alternate all-ASCII addresses will be required for some
combinations of actors (before you removed the text, it strongly
implied just that). If you allow them in the protocol and data
structure, then people who need to transmit them will have a
guide as to how to do so. If they are not allowed in the
protocol, they you would be actively encouraging different ways
of doing things by forcing different arrangements for
transferring that information. Given what everyone who has
studied database theory knows about the dangers of transmitting
closely linked data in separate pieces it is even more likely
that they will invent alternatives to this protocol as soon as
the requirement (or even an option) for transmitting an
all-ASCII alternative address to the registry arises.
(5) Finally, there is a procedural issue that seems to have
gotten lost in the other (particularly i18n) discussions. The
base EPP spec [RFC5730] says that there are three ways to extend
the protocol -- protocol, object, and command-response levels.
It does not say there can never be additional ways or that other
ways are not possible but it does say "three ways". This
document defines and adds a fourth, a "functional extension".
No matter how harmless that addition is and even if the WG is
certain it would never be used for anything other than this
particular spec (in which case the reasoning should probably
appear in the spec), that constitutes an update to 5730 that
should be appropriately reflected in the RFC header and other
document metadata. If it really were a change to allow changes
to the function of EPP (I don't think it is and believe the term
may be badly chosen), then the community is owed an explanation
of why the function and/or scope of an Internet Standard is
being changed as part of what ought to be a fairly minor
extension.
thanks,
john
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
